Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20416
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.0.16.2.20051125091637.02c6da38@zend.com>
Date: Fri, 25 Nov 2005 09:17:59 -0800
To: Rasmus Lerdorf <rasmus@lerdorf.com>,Ilia Alshanetsky <ilia@prohost.org>
Cc: Sascha Schumann <sascha@schumann.cx>,internals@lists.php.net
In-Reply-To: <43873C62.6030602@lerdorf.com>
References: <7.0.0.16.2.20051124161240.0573e640@zend.com>
	<20051125034515.6fefa4e2@localhost.localdomain>
	<43867C6C.2010209@prohost.org>
	<20051125040950.26305e08@localhost.localdomain>
	<43869FC5.4060708@lerdorf.com>
	<20051125075501.79718ee6@localhost.localdomain>
	<1132903004.9936.25.camel@localhost.localdomain>
	<pan.2005.11.25.07.40.45.515129@php.net>
	<1086017308.20051125091648@marcus-boerger.de>
	<Pine.LNX.4.62.0511251047430.31280@localhost>
	<Pine.LNX.4.64.0511251116430.1057@chatserv>
	<Pine.LNX.4.62.0511251131070.31280@localhost>
	<Pine.LNX.4.64.0511251138420.1057@chatserv>
	<438709AC.3020808@prohost.org>
	<Pine.LNX.4.64.0511251402220.5187@chatserv>
	<43870FE6.7040609@prohost.org>
	<43873C62.6030602@lerdorf.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break thousands of apps
	out there)
From: andi@zend.com (Andi Gutmans)

I must say that I feel deceived by this.
Derick and I agreed that this won't be enabled for 5.1, and he then 
took advantage of the fact that release managers changed to enable 
his class. Doesn't leave a good taste in my mouth and it shouldn't 
happen again in future.

Andi

At 08:31 AM 11/25/2005, Rasmus Lerdorf wrote:
>Ilia Alshanetsky wrote:
>>Sascha Schumann wrote:
>>>     I've seen that text.  It is hidden at the end of a paragraph
>>>     not related to the topic at all (something about class
>>>     constants).  As such it is totally inadequate.  There should
>>>     be a prominent point in the release announcement about
>>>     reserved symbols.
>>Does this include anytime a new function/class is added we need to make
>>a prominent notice about since it reserves some name space?
>>Bottom line there is a problem and we need a fix for it. One solution
>>that has been suggested is to revert the date class and release 5.1.1,
>>but this means we pretty much deny ourselves the ability to have a
>>native "Date" class in PHP. Is this really the only fix we can come up with?
>
>I don't think it ties our hands.  The current problem is that people 
>had about a week to prepare for this and the commit message of:
>
>   "Moved date constants into the date class, they all class constants now."
>
>didn't exactly trigger people to run out to fix this.  I was under 
>the impression that this date class was ifdef'ed out and although I 
>should have realized that it is impossible to move the date 
>constants to class constants without also enabling the class, I 
>didn't think of it when I saw this commit roll by.  So I feel 
>somewhat tricked by this and I don't like that.  I know it wasn't an 
>intentional thing, but Derick's view that "Gotcha!  It's in 5.1.0 
>now, so you can't change it" doesn't sit well with me either.
>
>As I stated before, core PHP does reserve the right to pick up the 
>most obvious keywords as we come up with new functionality, and I 
>think we should have a date class, but we should do it in an orderly 
>manner and give people some time to migrate to something that 
>actually makes sense.
>
>At this point I don't really care if we roll it back or give it some 
>obscure temporary name like date_ex which we can use as a temporary 
>placeholder while we work out what this class should look 
>like.  Despite all of Pierre's hot air, he does actually have some 
>good ideas in pecl/date that should be considered and Derick's 
>timezone code appears to be solid at least from the parts of it I 
>have used so far.  So let's just take a deep breath here, fix the 
>naming clash with pear and give them a chance to prefix their stuff 
>and provide a sane migration path for users and then come up with a 
>sensible plan for what the PHP date class should look like and work 
>with the pear guys to make sure they can actually use this new class 
>in their migration path.
>
>-Rasmus
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php