BTW, just to clarify, I am not against a Date class (whatever its
name) in the long run but I think it'd probably be a combination of
work Derick, Pierre and new contributions.
Andi
At 09:17 AM 11/25/2005, Andi Gutmans wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
