Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26208
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain emini.dk designates 192.38.9.232 as permitted sender)
Message-ID: <453D3B52.8000700@emini.dk>
Date: Mon, 23 Oct 2006 23:59:46 +0200
Organization: Emini A/S
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Marcus Boerger <helly@php.net>
Cc: internals@lists.php.net
References: <1485570655.20061023210857@marcus-boerger.de>
In-Reply-To: <1485570655.20061023210857@marcus-boerger.de>
OpenPGP: id=157D0FA8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] E_DEPRECATED
From: edink@emini.dk (Edin Kadribasic)

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