RE: [PHP-DEV] Design by Contract

From: 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

« previous php.internals (#82018) next »