[RFC] E_DEPRECATED View as Markdown

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

On Mon, 23 Oct 2006 21:08:57 +0200
helly@php.net (Marcus Boerger) 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

• 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 If removed in the next major version only. -1 otherwise.

It is already a nightmare to remember or manage the various changes in
all last minor releases.

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.

+1 for the other points, even if we can expect 5.2.0 for early 2007 ;-)

-- Pierre

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

• 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

. 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, but then we should also expand this to include:

- setting object variables without declaring them
- auto-creating objects of stdclass on the fly
- and other things that you *should* (not) do

These can be added later ofcourse, doesn't have to be directly in 
5.2.0, however that would probably be better.

. E_NOTICE or E_WARNING are used for input validations (e.g. domain errors).

+1, but I think we need to specify when exactly to use E_NOTICE,
E_WARNING, E_RECOVERABLE_ERROR and E_ERROR as well.

• 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, We should include E_DEPRECATED in E_ALL.

• 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

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

• 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

Hello internals,

+1, ditto on only major version for E_DEPRECATED to disappear

I'd go either way on E_ALL changing -- but would think that the Right
Thing is to leave it alone in 5.2, but make it mean ALL (even
E_STRICT) in 6.0

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Marcus Boerger 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:
+1 to them all.

Alan

Marcus Boerger 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

• 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).

+1

• 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

• 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

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

Edin

Marcus Boerger wrote:

• Add a new severity E_DEPRECATED

+1

• 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).

+1

• 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

--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

. 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.

At 21:08 23/10/2006, Marcus Boerger 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

• 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).

+1

• 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
I don't think we should change the names. A bunch of the
-recommended changes from the default file have nothing to do with
development/production, so differentiating based on that is not
accurate. Avoiding renames will also reduce the chance of confusion
(no big deal, but even the tiniest changes in such a central piece
tend to trigger questions).

I personally also don't see a good reason to disable E_WARNING and
E_NOTICE (and possibly also E_DEPRECATED) in a production environment

• you may still want to log such errors. As long as display_errors
  is off, it's not a problem except for the performance hit which
  should be low assuming you don't have too many of them.

• 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

Zeev

My vote (if it counts - can someone let me know if it does?)

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!"

Marcus Boerger wrote:

• Add a new severity E_DEPRECATED

Sounds like a good idea, +1 on the whole thing.

. 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.

Another idea (I haven't seen skimming through the replies):
Move use of undefined variable, property and index from E_NOTICE to
E_STRICT as it is a coding style question some people use to find typos.

Regards,

• Chris

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.
  . 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

• 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

0

• 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

Regards,

Michael