Re: [RFC] E_DEPRECATED

On 10/23/06, Marcus Boerger <helly@php.net> wrote:

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