On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass <sv_for...@fmethod.com> wrote:

    When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a typo. 
My choice isn't based as much on what the current error severity is, or what 
the error severity is supposed to represent in general, because I've found in 
PHP often the error severity has no connection with the error that's being 
reported. So I decided this by observing the real-world errors that use a 
certain severity.

    Many warnings and all E_STRICT errors clearly point to bugs in the code, 
wrong method signatures, non-existing variables and constants being used, which 
can easily do actual data damage if the script keeps running in undefined state 
(even if the engine is just fine with it).



  are you sure about that?
  E_STRICT is more about code that works but relying on some quirk or 
side-effect or simply does a stupid thing.

Well think about it. Why is it a goal to let quirky/stide-effect/stupid code 
run? This almost always ends badly.

It also reduces compatibility between code libraries. I.e.:


  it is the opposite, we allowed sloppy code in the past, and introduced 
E_STRICT to allow the pedantic people to find and fix the quirks and 
E_DEPRECATED for finding and migrating the code which will go away.

If you use a well tested, popular library by "sloppy" coders who don't mind 
E_STRICT and E_NOTICE, but you're "pedantic", what happens? You have to live 
with your error log filled with noise from the library or fork the library.

And when the "sloppy" coders miss bugs because they've decided the real PHP is 
about sloppy code that still works somehow, they miss bugs and then blame 
themselves or PHP for being a language that allows buggy code.

This is the end result if trying to turn PHP into everything for everybody. 
Instead, PHP should make up it's mind and stop littering the php.ini with 
semantics/behavior configuration for the language.

Have one behavior. Stick with it. Make it obvious.

Reply via email to