Fixing this date mess

php.internals

Rasmus Lerdorf

20 years ago
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. 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. -Rasmus

Pierre Joye

20 years ago
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

Sebastian Kugler

20 years ago
> 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

Michael Wallner

20 years ago
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

Sara Golemon

20 years ago
> 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

Oliver Grätz

20 years ago
Sara Golemon schrieb:
> I vote for #ifdefing it out of PHP5, and renaming PECL::Date to iDate or > Datei for PHP6 (in keeping with mysql tradition).
Datei? Yikes, that's "file" in german and would raise confusion ;-) OLLi

Lukas Smith

20 years ago
Sara Golemon wrote:
>> 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).
arg .. the "i" as in improved stuff is just as horrible as the "safe" stuff .. regards, Lukas

Jani Taskinen

20 years ago
On Fri, 25 Nov 2005, 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
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

Sebastian Bergmann

20 years ago
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

Michael Wallner

20 years ago
Sebastian Bergmann wrote:
> 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.
I assume you missed the existence and ignorance of pecl/date, but I must admit that I'm also skeptic about a cooperation between the two because of the recent past, but hey - they still can prove us wrong... :) Regards,
-- Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz

Sebastian Bergmann

20 years ago
Michael Wallner schrieb:
> I assume you missed the existence and ignorance of pecl/date
I was under the impression that was Derick's extension and that it was symlinked from the pecl CVS module into the php-src module. Sorry!
-- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Pierre Joye

20 years ago
On Sat, 26 Nov 2005 10:22:25 +0100 sb@sebastian-bergmann.de (Sebastian Bergmann) wrote:
> 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.
When you have no idea about problem please do not comment. Derick _requested_ me to do commit and/or publish this code until he was ready with only the TZ support, what he did just force me to change all my code to make it work in parallel. But you are right on one point, I doubt there will be cooperation between a liar and me. --Pierre