Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84752
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <CACwt+Je7mH0YWsFWL9+Lh9=nZmGUn8hRrJGmRk1wHtAnoeEJNQ@mail.gmail.com>
References: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com>
 <54FF8CED.5030701@gmail.com> <CAOsHV+sdkSnrB_ZSHE1T81rnBt1K58-_fOzt6-kjHpghmjV5kA@mail.gmail.com>
 <54FFC96D.6090004@gmail.com> <1579682575.9673.1426064704052.JavaMail.open-xchange@app06.ox.hosteurope.de>
 <55000A88.1030909@lsces.co.uk> <CAOsHV+sZbE3EMvxTe4esXaUebcA+GKnYbDLEdo8ZXXwY6UJBdg@mail.gmail.com>
 <CACwt+Je7mH0YWsFWL9+Lh9=nZmGUn8hRrJGmRk1wHtAnoeEJNQ@mail.gmail.com>
Date: Fri, 13 Mar 2015 21:37:47 -0300
Message-ID: <CAOsHV+shDOuXFxvo29vXAJXVfHRhbotrUaK5EpY3-UWrQy2vrg@mail.gmail.com>
To: Patrick ALLAERT <patrickallaert@php.net>
Cc: Lester Caine <lester@lsces.co.uk>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bf0f5feabcd8f051134d41f
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count
From: marcio.web2@gmail.com (Marcio Almada)

--047d7bf0f5feabcd8f051134d41f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi

2015-03-13 6:02 GMT-03:00 Patrick ALLAERT <patrickallaert@php.net>:

> Le mer. 11 mars 2015 =C3=A0 22:44, Marcio Almada <marcio.web2@gmail.com> =
a
> =C3=A9crit :
>
>> 2015-03-11 6:27 GMT-03:00 Lester Caine <lester@lsces.co.uk>:
>>
>> > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
>>
>> > Most of the examples being shown are examples of simple bad programmin=
g
>> > practice that needs fixing anyway, and I would expect a proper code
>> > review to have picked them up, so don't see that adding the check in P=
HP
>> > is essential. It would however be a useful addition but in the E_STRIC=
T
>> > category ... not that I want to maintain that, but being able to ignor=
e
>> > those errors until such time as it is appropriate to fix them.
>>
>
> I don't really see how this favors E_STRICT over E_NOTICE as any of this
> type of errors can be displayed/hidden independently.
>
>
>> I think this is a valid argument to keep the E_STRICT error level option
>> for the secondary voting.
>> That's a very useful information, thanks :)
>>
>
> It also depends on your perception of E_STRICT. This level has been
> introduced in 5.0 without being part of E_ALL in order to, among other
> things, avoid too much pain in the *** while migrating from 4.x to 5.x.
> As of 5.4, E_ALL contains E_STRICT and the difference between E_STRICT an=
d
> E_NOTICE/E_WARNING is certainly not in terms of severity.
> Using an undefined variable or property =3D> notice.
> Trying to get property of non-object =3D> notice.
> Use of undefined constant =3D> notice
>
> For this reason, I think we should use the standard notice/warning/error
> levels as much as possible. You may take a look at Nikita's "Reclassify
> E_STRICT RFC" for more info about it.
> https://wiki.php.net/rfc/reclassify_e_strict
>
> Cheers,
> Patrick
>

I talked to Nikita earlier today, in order to try to align the strict arg
count RFC with https://wiki.php.net/rfc/reclassify_e_strict and the
conclusion was the following:

It's a good thing to reclassify E_STRICT as this simplifies PHP error model
and resolves the currently unclear role of strict standards notices. As a
supporter of Nikita's idea, I'm removing E_STRICT from the voting options.
Consider this my collaboration to help to unifiy the error level model and
go a bit farther from the current "error level buffet" state we got
ourselves historically, on PHP.

This leaves us with E_WARNING vs E_NOTICE and I'm sufficiently comfortable
to allow a secondary voting between these two error levels.

Thanks,
M=C3=A1rcio

--047d7bf0f5feabcd8f051134d41f--