Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26201
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.166.176 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:in-reply-to:references:mime-version:x-priority:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=MW7R8ZcA3VqUirq+4fmINis2pq1aDOdPqa7gSNsrVR+6CKxPxTNgHw4hm1D30+g2nx64CWTHwzP5+dAgjrMOGsepf3fskwQCkGLEd7FQ/YS/k+cgnpWSiY8eqwhbPNsHhfJcjC0TR1GMaDnMdnexvFEkuvwPT0torOBl0cNpuPQ=
In-Reply-To: <1485570655.20061023210857@marcus-boerger.de>
References: <1485570655.20061023210857@marcus-boerger.de>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <4952541A-5786-4274-80B0-268C1A9BB0C0@prohost.org>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Mon, 23 Oct 2006 15:46:28 -0400
To: Marcus Boerger <helly@php.net>
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Re: [PHP-DEV] [RFC] E_DEPRECATED
From: ilia@prohost.org (Ilia Alshanetsky)


On 23-Oct-06, at 3:08 PM, 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.

+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