Le 13/07/2014 16:41, Zeev Suraski a écrit :
-----Original Message-----
From: Andrea Faulds [mailto:a...@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 <z...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
