RE: [PHP-DEV] Design by Contract
| From: | François Laupretre | Date: | Fri, 06 Feb 2015 07:29:22 +0000 |
| Subject: | RE: [PHP-DEV] Design by Contract | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-82018@lists.php.net to get a copy of this message | ||
> De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo Ohgaki
>
> Thank you for your time. It's based on annotation approach. This kind of
> implementation requires a lot of work...
I have an idea of a way to do it with limited work. Most important, everything would be in an
extension and would require no change in the PHP engine.
> I have more simpler approach in my mind based on current PHP language
> not to invent new language. I'll use syntax something similar to Dmitry proposed.
>
>Let me explain my original thought.
>
> Since we have reserved __functionname(), __some_functioname() should not have
> BC issues.
I understand your proposal but I repeat the same from the beginning : once modified, your code
cannot run in PHP 5 anymore (especially if you use 'require'). The (huge) BC break is
there, not in the fact that we use a hidden reserved function name.
Additionnally :
- that's a detail but I find that 'require' and 'ensure' are less intuitive
that 'in' and 'out'.
- invariants are for classes, not functions. Which syntax would you use ?
- I insist on the importance of checking 'smart' built-in phpdoc types because,
unfortunately, in PHP, most is_xxx() functions don't do what the user would intuitively expect.
Starting with is_int('123') returning false, while '123' is a correct int
argument value. The RFC will include a table of 'restricted' type juggling explaining the
rules to match phpdoc types with zval type/value.
Cheers
François