On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine <les...@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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
