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

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