Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84671
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.172 as permitted sender)
MIME-Version: 1.0
References: <CAF+90c-YX6tN63JwwWzn-WH2og2uffjR2YrL_JXsYKSjrQFS1Q@mail.gmail.com>
 <CACwt+JemDc_OVUxDV8ye0cjoXb3o+yoTtPZVG7eVQF7VrjPCoQ@mail.gmail.com>
In-Reply-To: <CACwt+JemDc_OVUxDV8ye0cjoXb3o+yoTtPZVG7eVQF7VrjPCoQ@mail.gmail.com>
Date: Fri, 13 Mar 2015 09:36:25 +0000
Message-ID: <CACwt+JcTwjhjTfhndZmwu08JB+CG1kuG=+=2mj2V3euwXB7piA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae9cc97c8f4b9a40511283bb3
Subject: Re: [PHP-DEV] Reclassify E_STRICT notices
From: patrickallaert@php.net (Patrick ALLAERT)

--14dae9cc97c8f4b9a40511283bb3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le ven. 13 mars 2015 =C3=A0 10:33, Patrick ALLAERT <patrickallaert@php.net>=
 a
=C3=A9crit :

> Hi Nikita,
>
> Le dim. 22 f=C3=A9vr. 2015 =C3=A0 23:31, Nikita Popov <nikita.ppv@gmail.c=
om> a
> =C3=A9crit :
>
> Hi internals!
>>
>> I would like to propose reclassifying our few existing E_STRICT notices
>> and
>> removing this error category:
>>
>>     https://wiki.php.net/rfc/reclassify_e_strict
>>
>> As we don't really have good guidelines on when which type of error shou=
ld
>> be thrown, I'm mainly going by what category other similar errors use. I=
'm
>> open to suggestions, but hope this will not deteriorate into total
>> bikeshed.
>>
>> Thanks,
>> Nikita
>>
>
> I am *very* glad you bring this subject on the table and I fully agree
> with the overall picture, I yet have to see the details as soon as I have
> some time.
>
> Just a remark regarding E_STRICT: since its introduction in PHP 5.0, it
> provided a way for people migrating from 4.x to 5.x with error_reporting =
=3D
> E_ALL to focus on the conversion of existing (legacy) application, while
> not forcing people to take care of changing things that "worked before bu=
t
> are now considered not so good" (yaaaaayyy, BC!).
> At the same time, people developing new applications could (via opt-in!)
> enjoy some more strictness thanks to this flag by adding it to the
> error_reporting.
>
> A few versions/years later, PHP 5.4 integrated E_STRICT as part of E_ALL
> and it encourages people to give attention to E_STRICT in addition to the
> other levels.
>
> However, we are again a bit in the same situation now: how could we
> provide extra information to PHP 7.x users (via opt-in) about things that
> we consider bad practice/behaviour abuse/side effect, but that will
> continue to work? E_DEPRECATED may sound fine, but not always as it *impl=
y*
> the feature will be gone some day.
>
> Could you think about this as this is somewhat related to E_STRICT histor=
y?
>
> A possible option (to investigate) would be to combine the various error
> levels with a new flag (E_NEW?):
>
>     zend_error(E_WARNING  | E_NEW, "This is a new warning as of 7.0!");
>
> For BC:
> People having E_WARNING as part of their error_reporting without
> activating E_NEW would not see it. Think about this as: it's PHP 5.0 with
> error_reporting =3D E_ALL (without E_STRICT then).
>
> For more errors verbosity (new application development):
> One can activate E_ALL reporting
>

FIX: s/activate E_ALL reporting/activate E_NEW reporting/


> (error_reporting =3D E_ALL | E_NEW or something else which doesn't expose
> the E_NEW flag ?) in order to see all new notices/warnings/...
>
> Later, instead of activating E_NEW by default (like including E_STRICT in
> E_ALL), the idea would be to remove the flag where appropriate so that:
>
>     zend_error(E_WARNING, "This is a new warning as of 7.0!");
>
> What's your opinion about this? (as a feature, not focusing on the
> details).
>
> Thanks,
> Patrick
>

--14dae9cc97c8f4b9a40511283bb3--