On 15 Jul 2014, at 13:50, Alain Williams <a...@phcomp.co.uk> wrote:
>> It will blow up with a fat E_RECOVERABLE_ERROR.
>> But this won't hold back the library authors from using it, which means
>> that the consumers of those libs has to start coding defensively, and make
>> sure that the variable holding the value 123 is an integer and not a float
>> or a string, because that will blow up something.
>
> They will have it blow up when it first runs, fix the bug (add a cast or
> something) and move on. I think that it is an insult to PHP coders to assume
> that they will not be able to cope. They will scratch their heads the first
> time
> that it happens to them, google/... & learn.
>
> The benefit of this is fewer issues in libraries. It may also help by catching
> user/coder errors earlier and so make their life easier.
>
> There is trade off bet
As has been pointed out previously, this isn’t good. People will simply do this
just to fix an error:
foobar((int)$_GET[‘thing’]);
However, an explicit cast can *never fail*. It will always return something,
whether it makes sense or not. This is simply going to lead to buggy software.
On the other hand, this RFC proposes a set of type hint casts which have
stricter rules than an explicit cast, and also somewhat stricter than
zend_parse_parameters, meaning that people can safely do $_GET[‘thing’] and
it’ll work, but if a nonsensical value is passed in, the program will error as
it should.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
