Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35332
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
Cc: "Gregory Beaver" <greg@chiaraquartet.net>,
 "internals Mailing List" <internals@lists.php.net>
Message-ID: <79C82941-9932-43D8-8CF4-9758B294659E@pooteeweet.org>
To: Pierre Joye <pierre.php@gmail.com>
In-Reply-To: <fe05d1540802080846v17b20915mf04dde3f5c4c9868@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Fri, 8 Feb 2008 18:09:23 +0100
References: <47AC8597.4060009@chiaraquartet.net> <fe05d1540802080846v17b20915mf04dde3f5c4c9868@mail.gmail.com>
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0, required 6)
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: [PHP-DEV] magic_quotes and the question of BC
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 08.02.2008, at 17:46, Pierre Joye wrote:

> On Feb 8, 2008 5:38 PM, Gregory Beaver <greg@chiaraquartet.net> wrote:
>
>> Frankly, I don't see why there is any vote whatsoever.  It's plain
>> stupid to consider removing them when a fully backwards-compatible
>> solution exists that has no performance penalty, no security penalty,
>> and in fact no penalty at all.
>
> It is not plain stupid to remove something when the underlying
> features do not exist. It is expected.
>
> Talking about BC in this case is a closed to be a complete non sense.
> For two reasons:
>
> 1. If can't do that between two major versions, let define a rule: we
> can't change _anything_ in PHP, no matter when (think: roll back all
> these fatal errors)
> 2. it is fixable in three lines (with braces). PEAR had much harder
> issues already, you can document the upgrade process (upgrade pear
> then php, make install will work if you include a full upgrading
> solution in go-pear.phar, if it is not the case already)
>
>
> Finally, I proposed a vote because we did vote about the _complete_
> removal of these features a while back. Back to this time, it was not
> decided to keep them but to actually completely remove them. I thought
> (and still think) that it was necessary (and it was necessary) to
> bring this topic back to the list and to finally have a choice. That's
> why this list exists and not whatever IRC channel somewhere on EFNet
> :)

Throw an E_DEPRECATED (means will be removed in the next major  
version) in PHP6 and return false for now.

-1

regards,
Lukas