Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77010
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.245 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CABBJUpedHeCArT+8YqUv906vQSbWJ_hvcjgbg-J5CNYZQhyHUg@mail.gmail.com>
Date: Mon, 1 Sep 2014 17:18:14 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A94D26CE-48FE-4642-94BF-330D4A43D925@ajf.me>
References: <E4EDB8A3-20DD-4DB9-AEB8-581B42222628@ajf.me> <CABBJUpedHeCArT+8YqUv906vQSbWJ_hvcjgbg-J5CNYZQhyHUg@mail.gmail.com>
To: Xinchen Hui <laruence@php.net>
Subject: Re: [PHP-DEV] Make zend_parse_parameters emit E_RECOVERABLE_ERROR
From: ajf@ajf.me (Andrea Faulds)


On 1 Sep 2014, at 04:56, Xinchen Hui <laruence@php.net> wrote:

> On Mon, Sep 1, 2014 at 6:01 AM, Andrea Faulds <ajf@ajf.me> wrote:
>> Good evening,
>>=20
>> Here=92s a suggestion: Why don=92t we make zend_parse_parameters emit
>=20
> ""Why not" is usually not a very good reason for a change in the =
language
> syntax. " =97 Stas

The reason isn=92t =93why not=94, 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=92s 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(=93     123abc.7=94);
    takes_int(new StdClass);
    takes_int(true);

It=92s only in quite rare cases that zpp will actually fail and emit an =
error, and in these cases you probably don=92t want your application to =
keep going. In the event you did, you could always make your error =
handler skip these errors. If nikic=92s 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 =3D=3D=3D NULL, as some =
functions return NULL for other reasons and this won=92t 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=92s 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=92s not something you=92re likely to be relying on (it=92s =
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/