Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23350
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Marcus Boerger <helly@php.net>
Date: Mon, 15 May 2006 02:39:02 +0200
Message-ID: <20060515023902.42fa7e93@localhost.localdomain>
In-Reply-To: <138663365.20060514205903@marcus-boerger.de>
References: <138663365.20060514205903@marcus-boerger.de>
Reply-To: pierre.php@gmail.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: E_ALL changes in 5.2/6.0
From: pierre.php@gmail.com (Pierre)

On Sun, 14 May 2006 20:59:03 +0200
helly@php.net (Marcus Boerger) wrote:

> Now the idea of E_STRICT is that core developers can inform users
> about changes in upcoming versions of php as early as possible. So
> developers should have E_ALL including E_STRICT enabled during
> development so that they are able to develop clean applications that
> most likely will work in the next version. On the production machines
> you would still either not use E_ALL or log only and don't show the
> errors in the application.

Sorry but I do not buy these arguments. As it is clear than nobody
should have display_errors On on a production servers, that does not
mean we can do that. I see it as a breakage.

> 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.

> 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.

> 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?


-- Pierre