RE: [PHP-DEV] Design by Contract

Hi Dmitry, > De : Dmitry Stogov [mailto:dmitry@zend.com] > Envoyé : lundi 9 février 2015 12:05 > À : Joe Watkins > Cc : Yasuo Ohgaki; Stanislav Malyshev; PHP Internals > Objet : Re: [PHP-DEV] Design by Contract > > invariant is for classes only. It should be called before and/or after each > method to check object consistency. > > syntax with expressions may work if we put constraints before the function > body . > > function foo($a int): int > require(expr1) > require(expr2, msg) > return(expr3) > { > } I understand you're defining an implementation based on assertions only, despite the fact that 'require' and 'return' are very ambiguous choices IMO. Did you take into account that, in many cases, this would revert to strict type checking, due to the way is_xxx() functions are working ? If someone writes 'function tan($op) / require (is_float($op));' will he expect tan(1) to be rejected ? (we're back to Rasmus' complaint). The same with is_int() and others, they're all based on zval types. Only is_numeric() is smarter and allows specifying a 'number' in the PHP way. Unfortunately, these functions are wrong as they don't fit with the way people are used to consider types in PHP. So, no easy way to say you can accept 1 or 1.0, let alone "1". That's why my proposal features assertions AND 'smart' argument types. Actually, types are more important than assertions because that's what people will use first. Primary use for assertions will be checking conditions between args. The same for properties and return type. Actually, I would say that most phpdoc-annotated code already contains most DbC constraints it needs. We just need to formalize and use them. As others already said here, be it for type checking or DbC, we need a mechanism to interpret types the 'PHP' way, something between PHP permissive type juggling and strict zval-based typing. That's what I tried to define. I understand the prevention against inserting PHP code in doc comments and, if I was designing the language from scratch, I wouldn't use such a design. But, considering every aspects of the problem, I still think it's the best compromise to add the feature. Regards François