Re: [RFC] E_DEPRECATED

My vote (if it counts - can someone let me know if it does?) On 23/10/06, Marcus Boerger <helly@php.net> 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&amp;r=213474731 "Standing on the shoulders of some very clever giants!"