This sounds very similar to preconditions in Design by Contract. However, preconditions validate input to the method as a whole, while the proposed syntax only checks individual arguments one at a time. Thus the proposed syntax has rather significan limitations compared to real preconditions.
For example, you could use preconditions to check whether a substring($str, $from, $to) call has valid parameters. The check would look like this: assert( $to < strlen($str) ) However, there is no way to do this without looking at _both_ $str and $to at the same time. What I'm saying is, if people are willing to go as far as checking individual parameters with userland functions, maybe there should be a serious discussion on introducing proper preconditions into the language? They are a tremendously useful tool for catching various bugs, and they would solve the type-checking problem as well. "Giovanni Giacobbi" <giova...@giacobbi.net> wrote in message news:20090710144118.gd20...@gerbil.thgnet.it... > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
