Re: RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_compile.c

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