Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23531
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <01fe01c678e0$7ea4e120$6602a8c0@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "PHP Internals List" <internals@lists.php.net>,
	"Ilia Alshanetsky" <ilia@prohost.org>
References: <6C67DAD9-B812-415A-BFD6-A4E963371551@prohost.org>
Date: Tue, 16 May 2006 14:01:36 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Flamewar Summary
From: steph@zend.com ("Steph Fox")

> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
> Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

E_RECOVERABLE_ERROR's apparently going in anyway.
E_STRICT, I'd be all for including into E_ALL now if it weren't for the 
'semi-statics' issue (complex) and the distributed INI default settings 
(simple). If PEAR:isError() legal doesn't actually do the Engine any harm 
then it'd make sense to keep it, purely as a BC consideration, in which case 
it shouldn't really need an E_STRICT if the purpose of E_STRICT is to warn 
about future BC breaks. Outside that, I personally find E_STRICT useful - 
it's helped me diagnose mystery crashes before now - but it's really only 
useful if it isn't over-used as an error level.

So -1, and some rethinking needed about the way E_STRICT is used ('this is 
the way you should do it' vs 'this is the way you will have to do it in 
future')

> As far as statics, there are no BC reasons not to do it that I can  think 
> of, but it just seems wrong to me from a design perspective to  allow 
> dynamic creation of static object properties.

It seems very PHP-ish to me to allow it. +1.

- Steph