Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58674
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
Received-SPF: pass (google.com: domain of tyra3l@gmail.com designates 10.229.135.208 as permitted sender) client-ip=10.229.135.208;
MIME-Version: 1.0
In-Reply-To: <4F563667.7080006@akbkhome.com>
References: <4F563667.7080006@akbkhome.com>
Date: Tue, 6 Mar 2012 17:28:39 +0100
Message-ID: <CAH-PCH5s3a25i5mv_FHgOpSAPfeDgnSrJn=WEsY+dP3hN5t3Sg@mail.gmail.com>
To: Alan Knowles <alan@akbkhome.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=00248c6a66d612c44004ba958951
Subject: Re: [PHP-DEV] consider reverting E_ALL with E_STRICT
From: tyra3l@gmail.com (Ferenc Kovacs)

--00248c6a66d612c44004ba958951
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 6, 2012 at 5:08 PM, Alan Knowles <alan@akbkhome.com> wrote:

> I just got caught on a production server with the 5.4 upgrade on debian,
> pretty much everything works fine, except the E_ALL change.
>
> I have to admit I missed the discussion where it was added, and searching
> for E_ALL or E_STRICT on marc is pretty difficult (it removes the E_ bit.=
.)
>
> Anyway, this change is a bit of an bomb on the code on the first server t=
o
> get hit with this, While i've never cared for E_STRICT (it's more like
> E_ANAL) - most of the warnings are pointless code tidy up's that only hav=
e
> pretty much zero cost/return in fixing.
>
> However, this change really kills code written by third parties, All our
> servers run with E_ALL on (eg. E_NOTICE is printed to end users) and we f=
ix
> instantly any errors that the end users see, as they are frequently issue=
s
> that should have been addressed. These applications are intra/extranet
> apps, not public websites.
>
> However with E_STRICT included we have to run around and find all the
> code, and change it to stuff like this:
>
> error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL);
>
> Could we please revert that, and if people want an all encompasing error
> mode, call it E_ANAL, like it was supposed to be...
>
> Regards
> Alan


it was proposed and voted in a "bulk" RFC, see
http://www.mail-archive.com/internals@lists.php.net/msg51887.html
the "Add E_STRICT to E_ALL" won by 58 to 0, so it was heavily supported by
the voters, and that was one of the things that was already decided and
commited in php6:
http://www.mail-archive.com/internals@lists.php.net/msg21822.html
I still think that E_STRICT can only serve it's purpose if our users are
seeing those messages, on a relevant note, also check out this thread from
Stas: http://www.mail-archive.com/internals@lists.php.net/msg52259.html

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--00248c6a66d612c44004ba958951--