Hi Marcus,
+1 to everything here if it counts, but please can you simplify the role of
E_DEPRECATED by making it 'next major version only'? I can see all kinds of
problems with leaving that open to debate.
- Steph
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
- 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.
. 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).
- 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
- 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.
You may respond with constructive ideas or complaints or go voting for all
or single points here, use -1, 0, +1 only. Please do not reply for the
sake
of responding, use pure voting instead as we are running out of time for
5.2.0 otherwise.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
