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
