Re: Return Type Hinting for Methods RFC

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 >