Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83669
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54EC262D.9050205@gmail.com>
References: <CAF+90c-YX6tN63JwwWzn-WH2og2uffjR2YrL_JXsYKSjrQFS1Q@mail.gmail.com>
	<54EC262D.9050205@gmail.com>
Date: Tue, 24 Feb 2015 16:02:47 +0100
Message-ID: <CAF+90c-3m15Zf6OVMqdukYJEO3cqnC+ya_gDvdaN+kkViKhFeQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0421a637cb5b60050fd6cf57
Subject: Re: [PHP-DEV] Reclassify E_STRICT notices
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d0421a637cb5b60050fd6cf57
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 24, 2015 at 8:20 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> >
> > 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
>
> Could you add some more explanation about why it is a good thing? I.e.,
> E_STRICT has pretty clear place and hurts no one, why remove it? What we
> are trying to accomplish by that? I'm just not seeing how it would be
> better without E_STRICT.
>

The motivation behind this is pretty ad-hoc. I have noticed that we have a
number of E_STRICT notices that seem pretty bogus and should be dropped.
I've also noticed that we throw E_STRICT for some imho relatively severe
errors (like signature mismatch, which fatals in other circumstances), in
which case the level should be increased. So in the end it's less about
"lets drop E_STRICT" and more about "after reclassifying some E_STRICT
notices, there isn't really anything left in this category".

In addition to that, I don't like the semantics that "strict standards"
notices convey. Many (professional) PHP developers target notice-free code
(which does not throw any kind of warnings/notices that are not explicitly
suppressed) and from this perspective "strict standards" notices are a
weird concept. Either the code is okay to write or it isn't, don't throw a
notice to tell me to "consider using an accessor" (because that
informational notice will present use in notice-free code). So this RFC
drops the portion of E_STRICT that appears bogus/informational to me (the
three mentioned in the RFC and the by-ref cases discussed in a separate
thread) and moves the rest to proper notices / warnings / deprecations.

Nikita

--f46d0421a637cb5b60050fd6cf57--