On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote:
> On 12/22/2011 07:08 AM, Keloran wrote:
>> i would love to see this expanded aswell (the way type hinting on function
>> variables was supposed to be), so that it could be
>>
>> string, int
>>
>> e.g.
>> function int test(bool $tester) {
>> if ($tester) { return 5; }
>> return 99;
>> }
>
> Return type hinting needs to be aligned with parameter type hinting, and
> as has been pointed out many times on this list, type hinting for
> interchangable scalar types is a really bad idea. It will push all type
> checking up to the caller of the underlying functions/methods. PHP is
> primarily a Web scripting language and the Web isn't typed. Having stuff
> like this break:
Have you taken a look at the RFC and/or patch? This functionality is exactly
aligned with parameter type hinting. Only classes, arrays and callables are
allowed types. I agree 100% on scalars.
>
> if(age_check($_POST['age'])) { do_stuff(); }
>
> because the author of the age_check() function added an int type hint
> just doesn't make any sense. It would cause everyone to have to start
> casting things everywhere, just in case. eg.
>
> if(age_check((int)$_POST['age'])) { do_stuff(); }
>
> This is not a step forward. If the author of age_check() really doesn't
> want to accept type-juggled arguments, then it is easy enough to do a
> strict type check in the function itself. This puts the effort in the
> correct place and doesn't encourage this type of coding.
It absolutely isn't. I'm also against the class casting RFC which would, in
effect, do this very same thing.
>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
