On 23-Oct-06, at 3:08 PM, Marcus Boerger wrote:
- Add a new severity E_DEPRECATED
- severities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away.
Eearlierst
removal would be two minor versions or one major version later.
That is
something that gets deprecated in 5.2 can be removed in 5.4.0
or 6.0.0.
However both marking it as deprecated as well as removing it would
require a consensus on the list.
+1 as long as a removal is set, not the "we may or may not remove
this, but here is a warning anyway". Once a component is marked with
E_DEPRECATED, the next major release it is out.
. 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.
. E_NOTICE or E_WARNING are used for input validations (e.g.
domain errors).
-1 In this case it seems like a pointless error level to me just
killing cycles. If you are not using questionable behavior that has
side-effects, why bother the user?
- We drop the current standard INI files and provide two new, namely
. php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED)
. php-production.ini for production (~(E_DEPRECATED|E_NOTICE|
E_WARNING))
. E_ALL does not contain E_STRICT or E_DEPRECATED
Rename rather then drop.
- 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.
-1 (not happening)
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
