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)
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
