On Mon, Feb 9, 2015 at 3:57 PM, François Laupretre <franc...@tekwire.net> wrote:
> Hi Dmitry, > > > De : Dmitry Stogov [mailto:dmi...@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). > You'll get exactly what you write in constraint, no any predefined semantic, no need to learn predefined rules. > > 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. > I think, people will use type hinting first (in a way they'll be implemented in PHP-7). Thanks. Dmitry. > 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 > > >
