Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26217
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <7.0.1.0.2.20061024074914.0d744b08@zend.com>
Date: Tue, 24 Oct 2006 07:53:27 +0200
To: Marcus Boerger <helly@php.net>
Cc: internals@lists.php.net
In-Reply-To: <1485570655.20061023210857@marcus-boerger.de>
References: <1485570655.20061023210857@marcus-boerger.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] [RFC] E_DEPRECATED
From: zeev@zend.com (Zeev Suraski)

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