Pierre, I agree with you that it was a bad idea to turn on the stub date class in the final release candidate giving people less than a week to notice that we now conflict with a common pear class. We get all the breakage and none of the benefits and nobody had any time to prepare the pear side of the house for this. It also sucks that not a single pear person tested the final RC and brought this up in the past week. There is plenty of blame to go around here.

Longer term we have to be able to move functionality from pear to php. That's one of the reasons pear exists. You can argue all you want over whose date implementation is better. In the end code speaks. I know you don't want to write any code unless you are sure it will be the chosen implementation, and I don't think you ever managed to convince everyone of the $date->m++ style of date manipulation. Not that this really matters, in the end what matters is actual working code. We will choose inferior working code over the perfect half-finished implementation every time. So, if as you say it will only take you an hour to implement, please do it so we can try it.

-Rasmus

Pierre wrote:
On Thu, 24 Nov 2005 21:52:28 -0500
[EMAIL PROTECTED] (Ilia Alshanetsky) wrote:

^
Pierre first of all I put the change in after a discussion with Derick
and a number of the while you were present btw. This was done to
declare the date class for "future" proofing and allow isolation of
date constants into a class, as is done for all new OO extensions.

You cannot trust Derick about ext/date, sorry.

He did not respect our decisions since he started to work on the TZ
support and force anyone to use the new implementation in 5.1.x.

I never agreed to anything Derick did in 5.x but was forced to shut up
and let him put some stupid object inside a #ifdef, as far as this crap
was in a #ifdef, yes I would have said, fine, we have time until php6.

I'll pretend that by "crappy" you mean limited, which it is because
all the methods are disabled till 5.1.1 when we will enable them to
allow a extensive test cycle.

It is crap, I need one hour to do it and I doubt Derick has any good
plan about a real new Date object API in php

But this is _not_ the problem, and you know that.

--Pierre


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to