Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78834
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.20 as permitted sender)
Message-ID: <545C2785.4010004@gmx.de>
Date: Fri, 07 Nov 2014 02:59:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Lester Caine <lester@lsces.co.uk>, 
 "internals@lists.php.net >> PHP internals" <internals@lists.php.net>
References: <CABRjmp-oqEVtX-igQWsr-JkFmitqxn4YsyJ=mnzyHCN9Kj7akA@mail.gmail.com> <CAH-PCH62GAecxC00aHgzgskG8zk58z1LBE1uBv81xtj6hRiy5w@mail.gmail.com> <3E2593DC-5755-48A6-8802-6F2FB3625778@ajf.me> <CAEZPtU5bdrgX3yfNZhPsWqrU6d5fw=vX78-iW=gx1jUJoeF8YA@mail.gmail.com> <04723EAD-4C8E-41C2-BE81-4989882A0C69@ajf.me> <545B26BB.9020406@lsces.co.uk> <545B589A.4010606@gmx.de> <545B66AB.2000109@lsces.co.uk>
In-Reply-To: <545B66AB.2000109@lsces.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Thresholds of backwards compatibility breaks
From: cmbecker69@gmx.de (Christoph Becker)

Lester Caine wrote:

> On 06/11/14 11:16, Christoph Becker wrote:
>>> Yes it is only a number, but a lot more problematic changes WERE pushed
>>>> through across those three versions which would have been much safer
>>>> handled by removing e_strict from PHP5.4 rather than trying to live with
>>>> both versions of PHP.
>> I don't see a problem with regard to E_STRICT.  If your code is not yet
>> strict compliant, simply turn it off for error_reporting:
>>
>>   error_reporting = E_ALL & ~E_STRICT
> 
> I get tired say this !!!
> 
> The problem is trying to maintain TWO totally incompatible code bases
> side by side. It is all to easy to have a wrong setting, or pick up a
> 'e_strict' version library with a not yet fixed set of code!
> If many of the libraries I work with had NOT been updated there would be
> less of a problem, but the ONLY way to prevent white screen sites is to
> get rid of all of the old code ... which is still unfortunately work in
> progress ...

Well, that's life.  If you have a car that needs leaded fuel, you might
have a hard time to drive it nowadays.

> Keeping the non e-strict code on a PHP5.2 powered server and only using
> e_strict compliant on the PHP5.4, we maintain stable operation, but
> ISP's are upgrading shared hosting and that is where ring fencing the
> legacy code is time consuming and detracting from getting code cleaned up.

Actually, you shouldn't have to have "strict" compliant code for PHP
5.4.  Ferenc pointed out a particular bug, where "non strict" code would
throw a fatal error, but this has been fixed, and there are several
general workarounds.[1]  If there are other bugs in this regard, you
ought to report these.

> And switching off error reporting only adds to the problems recovering
> sites which have gone down. I know people seem to think that this is not
> acceptable on production sites, but my code had always run clean and a
> visible error can be picked up and fixed while checking through a large
> number of log files across many services to see if there are problems is
> not something I want to spend my days doing!

Nobody suggested to switch off error reporting.  IMO, E_STRICT is
supposed to be a weak form of E_DEPRECATED, i.e. a hint for the
developer to modernize the code in the near future.  Until this can be
done, it seems to be perfectly fine to suppress *these* warnings.  When
the developer finds the time to fix the outstanding issues, running the
test suite in a development environment should catch most (if not all)
of them.  If there is no test suite, the developer is likely to be out
of luck anyway, IMHO.

> Screwing up the code and then hiding the results is NOT maintaining BC!

Apparently, the inclusion of E_STRICT to E_ALL wasn't supposed to screw
up anything.

[1] <CAH-PCH54+xOPYcpW8MPB45mjKSfbRMpgYbj=wPwBnP7_ymYdCQ@mail.gmail.com>

-- 
Christoph M. Becker