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. see http://www.mail-archive.com/internals@lists.php.net/msg24665.html about the original proposal and the discussion and you can see the list of E_STRICT errors in the 5.4 branch here: http://lxr.php.net/search?q=E_STRICT&defs=&refs=&path=%28*c%29+OR+%28*h%29&hist=&project=PHP_5_4 stuff like using non-existing variables and constants are E_NOTICE, method signature mismatches are either fatal errors or warnings AFAIR. > > 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. > 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. from all of the errors levels only E_DEPRECATED and E_STRICT is what means that atm your code works as intended. but for E_DEPRECATED it will not work in the future, and for E_STRICT it is either does it's job sub optimally or the requested operation is just stupid (but doable). at least this is the theory, if you know something with doesn't in line with this, we could talk about it. :) > > I've found this speeds up the development process, keeps bug count down > and protects the site/app's data in case of bugs. I agree that developing with E_ALL (including E_STRICT) is a good developer mentality. But I would find it too intrusive to start forcing everybody with the next version to either fix every E_STRICT in their code, and even more weird if we do that but still allow them to write code with full of E_WARNING and E_NOTICE and get away with that. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
