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
