Re: In regards to E_STRICT and PHP5

Why would you enable it then? You have to very explicitly enable it, as it's off by default, and doesn't get enabled even if you switch to E_ALL. I think it can help, and I don't see how it can hurt given the fact it's not on unless you want it to. Zeev At 19:30 16/06/2005, 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