Re: [RFC] Scalar Type Hinting With Casts (re-opening)

Le 13/07/2014 16:41, Zeev Suraski a écrit :

-----Original Message----- From: Andrea Faulds [mailto:ajf@ajf.me] Sent: Sunday, July 13, 2014 5:34 PM To: Zeev Suraski Cc: Nikita Popov; PHP internals Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) On 13 Jul 2014, at 15:31, Zeev Suraski <zeev@zend.com> wrote:

I think this is a big step in the wrong direction to one of the most common auto-conversion use cases out there (HTTP input variables). See my note to Nikita... This RFC is a huge deal, I suggest we let more people voice their opinion in before changing it in each direction :) Zeev

Yes, I might have acted a little too quickly. However, I'm not sure

"12a" is such

a common case. With the strict behaviour, foobar(" 12") and foobar("12")

still

work, however foobar("12 ") unfortunately would not.

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.

From my point of view, if the type annotations are doing implicit cast (with or without E_NOTICE/E_STRICT warning), they should behave exactly the same than an explicit cast. If it behaves differently, I'll be really difficult for a developer to guess what will be the PHP behaviour with this new syntax. Jocelyn