My vote (if it counts - can someone let me know if it does?)
On 23/10/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
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
+1 - Absolutely.
- 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 - At a major release would seem more appropriate, though
deprecating something near the end of the previous major release could
seem to be too quick.
. 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 - As an aside, it would be extremely useful to have the PEAR
classes marked as NON strict (in some way) until they are. I know this
is outside of the core, but using E_STRICT already means you have to
toggle off E_STRICT for PEAR. MAYBE STRICT (e.g. strict class PEAR
{...}) as a new keyword for a class, just so that you know that it IS
strict (or at least expecting to be).
. E_NOTICE or E_WARNING are used for input validations (e.g. domain errors).
+1/0 - Is this any different to what we already have?
- 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
-1 : As mentioned, if the developed code is notice/strict clean (and
it sure as hell should be), then the only major difference is
displaying of errors. The use of error and exception handlers should
be promoted to reduce the requirement of hiding errors.
- 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 : Whilst I would like to have everything and the kitchen sink in
PHP (I've got one in FireFox - actually doesn't make it any better
though), the longer the delay, the more problems there seems to be.
Have the cut off and fix faster! (Ok - that's just me being funny. Or
not! You are all working VERY hard to get this working for us, well,
me and all I do is make bad comments - but hey! Ain't open source
great? Community spirit and all that! Everyone chipping in with their
2cents worth ...)
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.
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
