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
