Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62787
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5045E044.9080809@lsces.co.uk>
References: <AANLkTimWuPXCs-HT6RgQYmH7UKcOYXkeTiMEnBwBXxnt@mail.gmail.com>
	<CAH-PCH4YdBr7WfQ2PR0_Fr_C=TfBsSGsbX3G-jonUqyfLrCcZQ@mail.gmail.com>
	<5040DC47.8000305@ajf.me>
	<CAH-PCH5TM2ag-5xm3Rk7Ef6LnpEst1UqRoc_f_Uwp_aLe418dA@mail.gmail.com>
	<5040F4D9.80206@sugarcrm.com>
	<CAEZPtU6X9gLRALzA+KGKNoF5c7ey-xgJ=0NhjF2qVfD9YJqN+Q@mail.gmail.com>
	<5042946A.80204@sugarcrm.com>
	<op.wjzdwn08idpuyk@damnation.nl.lo.geleia.net>
	<5042A7D6.7050001@lerdorf.com>
	<op.wjzgbuh1idpuyk@damnation.nl.lo.geleia.net>
	<alpine.DEB.2.02.1209031214250.25835@whisky.home.derickrethans.nl>
	<a565e97fdd574cebf2baca1c54c425a2@nebm.ist.utl.pt>
	<50452713.3020307@sugarcrm.com>
	<b6bf26cb6b4d2392d5fd13237669a19d@nebm.ist.utl.pt>
	<5045CAA3.6000409@lsces.co.uk>
	<CAEZPtU77K_wdRErqEQ1ZXj1_sWY2N_UcNkZsL5_h3UfjDmQK1Q@mail.gmail.com>
	<5045E044.9080809@lsces.co.uk>
Date: Tue, 4 Sep 2012 07:40:19 -0400
Message-ID: <CAL+t6cHD05znYaq7iPNwFNem=zma0-htbPG-Fc3550U-s5jcRA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
From: theanomaly.is@gmail.com (Sherif Ramadan)

On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine <lester@lsces.co.uk> wrote:
> Pierre Joye wrote:
>>>
>>> How many of the major PHP user projects ARE currently strict compliant?
>>> And
>>> >how many are still requiring E_STRICT switched off in PHP5.4?
>>
>> This is a development and very useful. PHP does not enforce this mode.
>> And like any other errors, it only ends in your logs.
>>
>> But this has been told to you a good dozen of times in the past, and
>> it is really getting ridiculous to have to explain that over and over.
>
>
> And the point of YOUR comments?
> With E_STRICT enabled - as is the default on PHP5.4 - programs simply crash
> if they have not been 'converted'!
>

E_STRICT can't crash you program. It's just like an E_WARNING or
E_NTOICE level error. It's non-fatal. It does not inhibit the
execution of code.

> The QUESTION is a perfectly valid one ... especially when I've just hit yet
> another current project that we have to make sure to disable E_STRICT when
> they get transferred to a PHP5.4 machine! I have no doubt a lot more will
> also be affected and so knowing the right answers is important. As perhaps
> is understanding the reason some projects are not converting code?
>

What exactly is the question that you're posing to PHP Internals? An
audit of how much code doesn't follow strict standards? Probably a
lot. I've seen plenty of it in production myself and among them even
the most popular PHP frameworks. Having tested Joomla on PHP 5.4
before a switch to production I recall seeing an actual drop in
performance due to the sheer number of E_DEPRECATED and/or E_STRICT
errors that the code produced.

However, none of that prevented the code from running (or "crashing"
as you say). All you have to do is change the error_reporting
directive if you chose to ignore those errors for the time being. You
simply don't have display_errors on in production anyway so the worst
possible outcome here is that you end up with an error log stuffed
with those errors. Nothing critical here.

This is not even a minor concern for most code basis that exhibit this
problem to a great degree because the majority of them aren't willing
to upgrade to 5.4 or have realized the problem by now and are fixing
their code.

> While the preference on PHP5.4 may be to force people to comply, the reality
> is that this is a switch which it's more likely needs switching off in
> production simply because user land has no idea how to handle the problems
> yet. And I'll keep banging on until what is distributed from the php.net
> site actually works on a current default install ...
>

The userland problem is a trivial issue. All they have to do is turn
display_errors off in production as is recommended and is the default
anyway. There is nothing major here to hold you back other than
yourself.

>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>