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.
