On Tue, Mar 6, 2012 at 5:08 PM, Alan Knowles <a...@akbkhome.com> wrote:
> I just got caught on a production server with the 5.4 upgrade on debian, > pretty much everything works fine, except the E_ALL change. > > I have to admit I missed the discussion where it was added, and searching > for E_ALL or E_STRICT on marc is pretty difficult (it removes the E_ bit..) > > Anyway, this change is a bit of an bomb on the code on the first server to > get hit with this, While i've never cared for E_STRICT (it's more like > E_ANAL) - most of the warnings are pointless code tidy up's that only have > pretty much zero cost/return in fixing. > > However, this change really kills code written by third parties, All our > servers run with E_ALL on (eg. E_NOTICE is printed to end users) and we fix > instantly any errors that the end users see, as they are frequently issues > that should have been addressed. These applications are intra/extranet > apps, not public websites. > > However with E_STRICT included we have to run around and find all the > code, and change it to stuff like this: > > error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL); > > Could we please revert that, and if people want an all encompasing error > mode, call it E_ANAL, like it was supposed to be... > > Regards > Alan it was proposed and voted in a "bulk" RFC, see http://www.mail-archive.com/internals@lists.php.net/msg51887.html the "Add E_STRICT to E_ALL" won by 58 to 0, so it was heavily supported by the voters, and that was one of the things that was already decided and commited in php6: http://www.mail-archive.com/internals@lists.php.net/msg21822.html I still think that E_STRICT can only serve it's purpose if our users are seeing those messages, on a relevant note, also check out this thread from Stas: http://www.mail-archive.com/internals@lists.php.net/msg52259.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu
