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
