On Sat, Aug 4, 2012 at 1:44 AM, Stan Vass <sv_for...@fmethod.com> wrote:
> ** > > > 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.: > my words aren't getting through to you. > > 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. > if we turn E_STRICT to behave exactly as E_ERROR there is no point keeping the E_STRICT level. personally I disagree with turning something which was a pedantic notice in one version into an unsupported feature which fatals out if you try to use it in the next. maybe E_STRICT->E_DEPRECATED->E_ERROR -- Ferenc Kovács @Tyr43l - http://tyrael.hu
