Fixing this date mess

On Fri, 25 Nov 2005 00:21:17 -0800
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:

We need to fix this date thing along with the Digest Auth mixup and
get a 5.1.1 out the door soon. I see Ilia committed a fix for the
Digest Auth thing, so assuming that this fix works, we just need to
figure out what to do with this date class. We can either roll back:

http://cvs.php.net/diff.php/php-src/ext/date/php_date.c?r1=1.43.2.20&r2=1.43.2.21&ty=u

or perhaps a better option is to rename that internal class for now
until we have a better idea of what this class is going to look like
and how we transition pear/Date users. Naming it date_ex (for
experimental) or something like that for now lets us keep the class
constants as they are and hopefully Derick and Pierre can come to
some sort of truce on the actual implementation. I don't think
having this mostly empty date class placeholder helps anybody right
now.

Put it back into the #ifdef.

This rename would also give us a migration path where you could have
a simple: class date extends date_ex { ... } wrapper which could then
be removed when we have the final internal date class implementation.

I' opposed to add a class now in 5.1, even with a rename, we better to
do what I explained you again this morning:

• Keep 5.x as it was, only the underlying code has been replaced

• take the time to define, implement, document and test a new date/time
  API in php6, we can even do that in pecl and put it in php-src at a
  later point

--Pierre

This rename would also give us a migration path where you could have a
simple: class date extends date_ex { ... } wrapper which could then be
removed when we have the final internal date class implementation.

IMVHO this is a good idea. At least I greatly appreciate that it
wouldn't break applications just for the sake of having a namespace
for constants and "future proofing".

I don't think having this mostly empty date
class placeholder helps anybody right now.

It seems to for some people, but for the majority of PHP application
developers out there it does the exact opposite.

Regards,
Sebastian

Rasmus Lerdorf wrote:

We can either roll back
+1

or perhaps a better option is to rename that internal class for now

--
Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz

We can either roll back:
http://cvs.php.net/diff.php/php-src/ext/date/php_date.c?r1=1.43.2.20&r2=1.43.2.21&ty=u

or perhaps a better option is to rename that internal class for now
I vote for #ifdefing it out of PHP5, and renaming PECL::Date to iDate or
Datei for PHP6 (in keeping with mysql tradition).

-Sara

We need to fix this date thing along with the Digest Auth mixup and get a
5.1.1 out the door soon. I see Ilia committed a fix for the Digest Auth
thing, so assuming that this fix works, we just need to figure out what to do
with this date class. We can either roll back:

http://cvs.php.net/diff.php/php-src/ext/date/php_date.c?r1=1.43.2.20&r2=1.43.2.21&ty=u

or perhaps a better option is to rename that internal class for now until we

 Either keep it as is or nuke it forever. But please, no pingpong here.

have a better idea of what this class is going to look like and how we
transition pear/Date users. Naming it date_ex (for experimental) or something
like that for now lets us keep the class constants as they are and hopefully
Derick and Pierre can come to some sort of truce on the actual implementation.

 I wouldn't hold my breath waiting for that to happen.

I don't think having this mostly empty date class placeholder helps anybody
right now.

 It already helped. People woke up. :) Make a big fat notice about it and
 let it blow things up and we end up with something better.

 --Jani

Rasmus Lerdorf schrieb:

Pierre can come to some sort of truce on the actual implementation.

At least there is code from Derick on the table. If Pierre needs as much
time to show code for his Date extension than he needs for PIMP -- which
is his good right and I am not {b|f}laming here -- I doubt that there
will be frugal cooperation between the two.

--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69