Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23357
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 15 May 2006 09:13:53 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <434508964.20060515091353@marcus-boerger.de>
To: Pierre <pierre.php@gmail.com>
Cc: internals@lists.php.net
In-Reply-To: <20060515023902.42fa7e93@localhost.localdomain>
References: <138663365.20060514205903@marcus-boerger.de> <20060515023902.42fa7e93@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: E_ALL changes in 5.2/6.0
From: helly@php.net (Marcus Boerger)

Hello Pierre,

Monday, May 15, 2006, 2:39:02 AM, you wrote:

> On Sun, 14 May 2006 20:59:03 +0200
> helly@php.net (Marcus Boerger) wrote:

>> That said i am about to not remove E_STRICT from E_ALL and MFH the php
>> 6.0 to item just now.
>> See: http://oss.backendmedia.com/PhP60  (add E_STRICT to E_ALL DONE
>> (dmitry))

> It was planed for 6.0 for a good reason. 5.1.x is dead, but we are
> fixing many issues (including security problems) in 5.2.x, many people
> will not update because of the "breakages". I see that as a strategic
> mistake.

You are speaking of PHP 4 people here.

>> Since this is for the benefit of the users to prevent issues with
>> changes in behavior from my opinion it is best to do this behavior
>> change as early as possible, which is in my opinion 5.2 anyway.

> On the other side it is for the benefit of our users to prevent
> breakages and useless annoyances.

If you don't like E_STRICT you can simply set E_ALL without it in your
ini, stay with a version of your likes as Steph suggested and live happily
ever after.

>> That said i'll let it in and if there is no valid argument against, i
>> will put it into the NEWS file and the newly started
>> README.UPDATE_5_2.

> I already asked you (without answer) to tell me which cases you
> consider critical and thus should be moved to E_ALL. Which are they?

Critical? I said that any changes that have a behavior impact should be
documented. I hope i didn't miss anything besides E_STRICT which faith
hasn't been decided yet.

But guess what, you're more then welcome to update and write additions
to the update file instead of only complaining.

Best regards,
 Marcus