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).
PHP should not split the language semantic into loose, less loose and
strict, there should be just one set of semantics: the PHP semantics, and
when code does something that doesn't fit, it shouldn't be an ignorable
warning.
I've found this speeds up the development process, keeps bug count down and
protects the site/app's data in case of bugs.
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
