--- 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. > At 09:30 AM 6/16/2005 -0700, boots wrote: > >I was hoping that in the future, E_STRICT wasn't expanded and was > >perhaps even taken back a step. I understand the reason for it: code > >correctness. Yet if PHP5 is (rightly) considered a runtime engine > then > >its job should be to evaluate and execute code and in the case of > >failure, explain why it could not do so. In other words, if a code > >segment is valid, then the runtime should just do its job and run > that > >code. Code correctness is the job for offline tools like lint. Yes, > PHP > >is a dynamic language so things like E_NOTICE are often required to > be > >triggered by the runtime. Yet the only place keywords can be > generated > >dynamically is through an eval -- and I suggest that getting > deprecated > >warnings at that point is not very enlightening. There is another > >difference between an E_NOTICE and a deprecated warning: the first > can > >lead to (or mask) programming errors, the second can not. Its almost > as > >if another error flag (not error level) was needed, something like > >E_DEPRECATED. The real question is, should the runtime be concerned > >about that or should that be something that the toolchain handles? I > >would rather the latter. > > > >If there is any merit to E_STRICT as it stands currently I find it > to > >be negated by the fact that it throws messages for completely > >acceptable code that the engine is both willing and capable of > >handling. If var is not acceptable, I think it should be removed as > a > >keyword. If it is acceptable, the engine shouldn't complain about > it. > >(of course, I think it is acceptable.) > > > >Very best regards and thanks. > > > >-- > >PHP Internals - PHP Runtime Development Mailing List > >To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
