On 13 Jul 2014, at 15:41, Zeev Suraski <z...@zend.com> wrote: > I don't think it's a common intentional case, but when writing code > defensively - you need to be prepared for whatever someone might through > at you... Say I have a form that accepts 'age', and I expect users to > type in their age. As one that develops the backend, it's great if I can > simply stick an 'int' in the function signature that deals with this > $_GET['age'], and know that whatever the user typed in - it would turn it > to the most sane integer value. In other words, if someone types in '12a' > (by mistake or intentionally), I think it's a very sane behavior to just > treat it as 12, as opposed to forcing me (the developer) to write error > handling code with a try/catch block, and a fairly hairy try/catch block > too. Your example of "12 " (that I didn't even think about before) is an > even a more likely scenario, but I think there's no strong reason not to > allow both.
I can see what you’re getting at, but then I also think allowing “12a” and the like could be a source of bugs. In this particular case, I’d probably explicitly cast the age myself before doing anything with it. Forbidding “12a” is closer to the other type hints, which are strict, but is also further away from zpp. I’m a big conflicted. For now, I’ll leave it as E_RECOVERABLE_ERROR. While user input might be problematic, it can just be filtered. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
