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_ymy...@mail.gmail.com>

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to