On 10/23/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
. E_DEPRECATED: Some language featre that is likely to go away.
s/likely/confirmed/. We can't speculatively deprecate a feature and
then change our minds. (The {} vs [] thing with strings comes to
mind).
I don't think we need to set any firm ground rules for the deprecation
timeline but should consider each change individually. A reasonable
rule of thumb is to remove deprecated features no sooner than 1 minor
release after the deprecation notice was added. Ideally, it should be
in a major release.
+1
. E_STRICT any rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.
+1
Note that if we are going to treat implicit property setting as
E_STRICT then we should exclude stdClass from generating those
warnings, otherwise you can't work with deliberately created dynamic
objects.
- We delay 5.2.0 and revisit all errors and change them according to the
new model. We also put any change into the upgrading file.
+0.
Let's just delay 5.2 long enough to make sure we haven't accidentally
promoted E_STRICT to fatal errors in 5.2.
--Wez.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
