These answers make me feel as if maybe just a little bit you guys are looking down your nose at me without really considering the basis of the issue I am trying to raise. I know the tools well enough to use E_ALL -- thanks. I'm concerned about end users who don't know enough to help themselves -- but whom I have to support. I'm talking about problems running PHP4 codebases on a PHP5 engine.
So what can I reasonably do? My options seem to be: a) recode my PHP4 apps; b) explain to my clients the reasons for the "errors" and what to do about them; c) tell them not to upgrade to PHP5 and avoid the situation entirely. Those are all bad solutions in my mind and they stem from the simple fact that error reporting is being used to report non-error conditions. Just as try/catch shouldn't implement application logic, it is reasonable to assume that error reporting will be constrained to bona fide errors. E_STRICT is a wonderful idea -- I just wish it was implemented separately from the normal error handling, that's all. An important thing to remember is that a client's configuration, PHP version and codebase mix is typically out of my control and I don't like looking bad just because the runtime is taking it on itself to tell the world about irrelevant differences between PHP4 and PHP5. Those differences are important to you and me, not end-users. Is it a huge issue? Absolutely not! Still, it is exceptionally annoying and it can be avoided (simple: just send E_STRICT to its own logfile). As I said before, I am satisfied to have my say and I completely respect your decisions. I am also grateful for the kind treatment and responses I received. So I apologize for the interuption and this time I will bow out -- unless someone else thinks it is necessary to tell me about E_ALL. Greetings. --- Andi Gutmans <[EMAIL PROTECTED]> wrote: > I suggest you use E_ALL. > > At 11:50 AM 6/16/2005 -0700, boots wrote: > >--- Andi Gutmans <[EMAIL PROTECTED]> wrote: > > > You missed the point of E_STRICT. I introduced it as an > E_PEDANTIC. > > > That was the whole idea. To be pedantic about code that works, > not > > > to warn about code that doesn't work (which is for higher > warning > > > levels) > > > >I don't think I missed that, I just don't appreciate it :) I'm > >suggesting that its not the business of a runtime engine to be > pedantic > >-- it is the author and the development toolchain that needs to be > >pedantic. I think it is noble to implement linting and other > checking > >in the engine, but in my view that is best enabled by a command line > >option rather than an ERROR reporting level. The basic thing I am > >getting at is that it causes more confusion than is warranted by the > >value of the information it provides. > > > >So, while it is agreeable to give tools to developers that help them > >produce more "correct" code the value is lost when it adds to > developer > >cost in a non-meaningful way. Those same developers that the engine > is > >trying to help is causing them to repeatedly answer customer queries > >and explain that an "error" is not an "error" even though the PHP > >engine says it is. The fact that it IS pedantic and unneccessary > just > >makes it that much harder to appreciate. > > > >It comes down to this: if the PHP5 engine can run a piece of PHP4 > code, > >it would be very nice if it just did that. One expects error levels > to > >tell of code problems, not code niceness. It is not that I don't > >understand where you are coming from and I certainly appreciate the > >fact that you are looking out for developers. I am trying to impart > the > >idea that it is actually working against us in this instance. > > > >All the best. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
