On 1 Sep 2014, at 04:56, Xinchen Hui <larue...@php.net> wrote:
> On Mon, Sep 1, 2014 at 6:01 AM, Andrea Faulds <a...@ajf.me> wrote:
>> Good evening,
>>
>> Here’s a suggestion: Why don’t we make zend_parse_parameters emit
>
> ""Why not" is usually not a very good reason for a change in the language
> syntax. " — Stas
The reason isn’t “why not”, the reason is to improve consistency and make
programs safer. This makes zpp consistent with userland type hints (less user
confusion), and also means programs can failsafe rather than trundle on and do
something stupid.
>> E_RECOVERABLE_ERROR on failure, rather than just emitting E_WARNING and
>> returning FAILURE (causing the caller to typically bail out and return NULL)?
>> This would bring it into line with userland type hints, which also cause such
>> errors. It might also cause errors to be caught sooner, as just returning
>> NULL
>> can cause cryptic problems down the line. It’s worth noting that
>> zend_parse_parameters is very tolerant in terms of what parameters you can
>> pass
>> it and is unlikely to error unless you do something really weird such as
>> passing an array to strlen().
> PHP is a looser type language... such things might be happened. and
> internal functions always check their arguments.
Certain types of type shift are uncommon. zpp is extremely tolerant, as it
should be in a weakly-typed language, so all of these would work:
takes_int(1);
takes_int(1.0);
takes_int(“ 123abc.7”);
takes_int(new StdClass);
takes_int(true);
It’s only in quite rare cases that zpp will actually fail and emit an error,
and in these cases you probably don’t want your application to keep going. In
the event you did, you could always make your error handler skip these errors.
If nikic’s exceptions in the engine RFC is revived, you could even do this:
try {
takes_int($something);
} catch (InvalidArgumentException $e) {
// Handle gracefully
}
Which would be more robust than checking for === NULL, as some functions return
NULL for other reasons and this won’t spit out an E_WARNING.
To help BC, we could even make it do the old thing if @ is being used to
silence it.
> this will make the PHP app more robust.
I think applications are more robust if they fail early rather than plodding
along because the programmer forgot an error check, and hence corrupting data
or worse.
>> I doubt this would affect backwards compatibility
>> much, unless your application relies on a silenced warning (which is
>> possible,
>> but discouraged behaviour), and it’s the type of BC break that would be
>> really
>> obvious (your application errors and stops execution).
> that will be a nightmare to stop people upgrade their PHP.
I doubt it. It’s not something you’re likely to be relying on (it’s a failure
case), and if it is, you can use an error handler to skip the error and get
your old behaviour.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
