Re: Type hinting - Request for Discussion

On Fri, Jul 10, 2009 at 01:40:47PM +0200, Lukas Kahwe Smith wrote: > > On 10.07.2009, at 13:20, Lewis Wright wrote: > > >>3) function Foo(is_int($x)) { > >> > >>Function is_int is called, an error is raised if it returns false. > >> > > > >But then you're complicating it to the point where it's no longer > >much more > >useful than just calling the is_numeric method in the function body. > >Plus > >there's no longer the advantage of optimisers knowing the data-type. > > > right .. lets not forget the original goal (though it hasnt been > perfectly defined) > the idea was to move common validation code out of the function body > to reduce code, increase readability and enable IDE's to be even > smarter. > moving the function body into the signature was not the plan, as it > will kill the above features for the sake of flexibility. > the point is not flexibility, its finding a sensible common > denominator for validation of input parameters and optimizing the > syntax for that case. > Well actually I think the idea was to REPLACE the current syntax with the contract specification, because it includes both the strict and weak typing, plus it adds a powerful extensibility to the type checking system to user space. Also, we are not moving the function body into the signature, because it's not a "statement" but a specific single function call. The grammar will be very strict about what goes inside the signature: at most one single function name, followed by any number of arguments which can either be a $var, or a constant but NOT an expression. It should be possible also to use another syntax: function ContractHint(is_int:$a, $b, is_multiple:$c:5) { ... } but I prefer the normal notation: function ContractHint(is_int($a), $b, is_multiple($c, 5)) { ... } They look like function calls, but they are NOT function calls in fact. The executor will call them for each parameter, checking the (bool) returned value and raising a detailed error with the current line where the type checked function is called. If you write your own checking code, raising an error with trigger_error(), the error line reported will be inside the type checked function, which is not very helpful for debugging (in fact I always have to debug_backtrace() to find something useful). There is NO ambiguity with current type hinting, you can still have classes with the same name: class is_int { } function StandardHint(is_int $a); IDEs can still act smart because is_int() is a PHP standard function, and we could add a few more like cast_int(), and is_int_null(). -- Giovanni Giacobbi