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. 2) programming choices that can cause unpredictable behavior (can't think of any examples off the top of my head, but & references certainly qualify) This way, it could be used as an uber-lint on PHP code on the development machine, rather than as some kind of runtime dominatrix. I think that post-5.0.0 changes to E_STRICT have shown decisively that it is a royal pain in the ass to code around all the changes (look at the removal of "var" from E_STRICT, for instance) and does not add any real value. *Real* errors should be at least E_NOTICE, like the return by reference issue. Coding style should never be enforced at the language level, leave politics to people, machines suck at it. Greg [1] http://marc.theaimsgroup.com/?l=php-dev&m=106920278629010&w=2 Ilia Alshanetsky wrote: > Adding more error modes is fine and dandy, but it has to be with a good > reason in mind. In my mind if we add E_DEPRECATED and mark certain > behavior as deprecated it means in a certain version, PHP6 (for example) > it will go away and no longer work. Marking something as deprecated with > no intention to actually remove it at a given point is pointless, why > have the check in the first place, waste a few extra CPU cycles? > > > On 21-Oct-06, at 11:28 AM, Lukas Kahwe Smith wrote: > >> Marcus Boerger wrote: >> >>> That said I can only repeat here what I said earlier on IRC. Lets do >>> things >>> right and make the more complex OO rules as E_STRICT and create new >>> severity >>> level E_DEPRECATED. E_STRICT will then only be used for 'pedantic' OO >>> rules >>> while E_DEPRECATED will be used for stuff that is considered bad >>> practize >>> and that might be removed in later versions. For me later would best >>> be a >>> rule like earliest two minor versions later. If we do so we create a >>> situation wher I hope everyonecan get happy. All users can be >>> informed about >>> upcoming changes using E_DEPRECATED and the OO supporters enable >>> E_STRICT >>> while the dynamic fraction disables it. Last but not least i would >>> like to >> >> I would be very happy with this solution. >> >> regards, >> Lukas >> >> --PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
