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

Reply via email to