Gregory Beaver wrote:
Hi Ilia and everyone,
E_DEPRECATED makes good sense - it can be a big warning flag that
something will be removed, and will make it very easy to code around
changes. Once something is E_DEPRECATED, however, it must stay that
way, I agree with Ilia.
The point of E_STRICT as originally stated was for purists, but was
blurred^M^M^M^M^Mmodified to mean both purity and deprecated behavior
[1] that will be removed.
<rant>
If E_STRICT is just for anal-retentive developer candy, then why the
hell have it at all? It just causes wasted developer oxygen, forget CPU
cycles.
Enforcing "proper" OO as defined by arbitrary choices made earlier in
the 1990s by big-brained scientists does not make my programming life
easier. Why not let developers decide how to structure their code? You
can't turn a bad coder into a good coder by E_STRICTing him/her to
death. Nor can you turn a good coder into a bad coder by allowing
fringe OO design possibilities that neither slow down the language nor
make it harder to maintain.
</rant>
E_STRICT does have a valid use, in my opinion. It should only be used for:
1) programming choices that can cause major performance issues, i.e.
opcode cache-unfriendly code.
Well, a lot of things are opcode cache unfriendly. This would mean that
include_once, autoload, conditional includes, conditional function and
class definitions and a bunch of other things would all fall under
E_STRICT. That doesn't sound feasible to me.
For non-sensical code, I do see value in throwing an E_STRICT. Although
I suppose that could also fall under E_NOTICE.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
