Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84670
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
MIME-Version: 1.0
References: <CAF+90c-YX6tN63JwwWzn-WH2og2uffjR2YrL_JXsYKSjrQFS1Q@mail.gmail.com>
In-Reply-To: <CAF+90c-YX6tN63JwwWzn-WH2og2uffjR2YrL_JXsYKSjrQFS1Q@mail.gmail.com>
Date: Fri, 13 Mar 2015 09:33:39 +0000
Message-ID: <CACwt+JemDc_OVUxDV8ye0cjoXb3o+yoTtPZVG7eVQF7VrjPCoQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043be1dc0d05340511283295
Subject: Re: [PHP-DEV] Reclassify E_STRICT notices
From: patrickallaert@php.net (Patrick ALLAERT)

--f46d043be1dc0d05340511283295
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Nikita,

Le dim. 22 f=C3=A9vr. 2015 =C3=A0 23:31, Nikita Popov <nikita.ppv@gmail.com=
> a =C3=A9crit :

Hi internals!
>
> I would like to propose reclassifying our few existing E_STRICT notices a=
nd
> 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 shoul=
d
> 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 but
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 *imply* the
feature will be gone some day.

Could you think about this as this is somewhat related to E_STRICT history?

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 (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

--f46d043be1dc0d05340511283295--