# PHP 5.1 - Thread: https://externals.io/message/20321 - Original archive: https://news-web.php.net/php.internals/20321 - Started by Andi Gutmans on 2005-11-25T00:15:04+00:00 - Messages: 136 - Page 1 of 6: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/20321.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #20321 — Andi Gutmans — 2005-11-25T00:15:04+00:00 URL: https://externals.io/message/20321#20321 Hey, Just wanted to thank everyone who helped get PHP 5.1 out of the door after a lot of efforts. Special thanks to Steph who stepped up to make the upgrading guide happen. I think this should become a standard for future PHP releases. Also thanks to Ilia who picked up the last few rounds of PHP 5.1 release management to make it happen. Well done everyone! Andi --- ## #20324 — Pierre — 2005-11-25T02:45:15+00:00 URL: https://externals.io/message/20321#20324 · In reply to: #20321 On Thu, 24 Nov 2005 16:15:04 -0800 andi@zend.com (Andi Gutmans) wrote: > Hey, > > Just wanted to thank everyone who helped get PHP 5.1 out of the door > after a lot of efforts. > Special thanks to Steph who stepped up to make the upgrading guide > happen. I think this should become a standard for future PHP releases. > Also thanks to Ilia who picked up the last few rounds of PHP 5.1 > release management to make it happen. > > Well done everyone! Well Done Derick who did again what's the hell he wants. If anyone can show me we agreed to put the crappy (yes crappy) new date object ON by default in 5.1.0. We agreed to not active it by default but let it under the experimental #ifdef so Derick can still be lazy and use the same tree to maintain his stuff. I ask to stop the realease process, put all this Object date back in the experimental #ifdef and roll 5.1 again. --Pierre --- ## #20325 — Ilia Alshanetsky — 2005-11-25T02:52:28+00:00 URL: https://externals.io/message/20321#20325 · In reply to: #20324 Pierre wrote: > On Thu, 24 Nov 2005 16:15:04 -0800 > andi@zend.com (Andi Gutmans) wrote: > > > > […] > > > Well Done Derick who did again what's the hell he wants. 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. > If anyone can show me we agreed to put the crappy (yes crappy) new date > object ON by default in 5.1.0. 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. Ilia --- ## #20326 — Pierre — 2005-11-25T03:09:50+00:00 URL: https://externals.io/message/20321#20326 · In reply to: #20325 On Thu, 24 Nov 2005 21:52:28 -0500 ilia@prohost.org (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 --- ## #20330 — Rasmus Lerdorf — 2005-11-25T05:23:17+00:00 URL: https://externals.io/message/20321#20330 · In reply to: #20326 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 > ilia@prohost.org (Ilia Alshanetsky) wrote: > > ^ > > […] > > 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. > > > […] > > 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 --- ## #20331 — Pierre — 2005-11-25T06:55:01+00:00 URL: https://externals.io/message/20321#20331 · In reply to: #20330 On Thu, 24 Nov 2005 21:23:17 -0800 rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > 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. No, do not blame anyone but the one who commited the change and the one who agreed. Do not expect me neither to come up with any complaints, you know how it ends when I try. > 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. Wrong, in the end the one who commits without giving a single shit to anyone wins, in this case, Derick. You can argue or say all rethoric you have about code, commits, contribution or cooperation, facts are that from day #1 the game is biased. If I did not ask and simply commit my code in 5.0 branche, It would have gave two possible things: - I lost my karma - my code will be already in 5.0 Conclusion? I have to be an ass and do what I want, not what other could expect. > 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. I proposed, I convinced people (read the archive if you do not remember), but my way was too nice and slow for Derick. > 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. What I say it is I need one hour to implement a brain dead OO interface like this one around this API. And what really matters anyway? --Pierre --- ## #20332 — Alan Knowles — 2005-11-25T07:16:43+00:00 URL: https://externals.io/message/20321#20332 · In reply to: #20331 This one's a bit more annoying than usual ;) It will basically break application that depends on the Date package (eg. most of my code as DataObjects uses it internally).. Do we really need another barrier to upgrade to 5.*? Regards Alan > On Thu, 24 Nov 2005 21:23:17 -0800 > rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > > > […] > > No, do not blame anyone but the one who commited the change and the one > who agreed. > > Do not expect me neither to come up with any complaints, you know how > it ends when I try. > > > […] > > Wrong, in the end the one who commits without giving a single shit to > anyone wins, in this case, Derick. You can argue or say all rethoric > you have about code, commits, contribution or cooperation, facts are > that from day #1 the game is biased. If I did not ask and simply commit > my code in 5.0 branche, It would have gave two possible things: > > - I lost my karma > - my code will be already in 5.0 > > Conclusion? I have to be an ass and do what I want, not what other > could expect. > > > […] > > I proposed, I convinced people (read the archive if you do not > remember), but my way was too nice and slow for Derick. > > > […] > > What I say it is I need one hour to implement a brain dead OO interface > like this one around this API. > > And what really matters anyway? > > > --Pierre --- ## #20333 — dufuz@php.net — 2005-11-25T07:40:47+00:00 URL: https://externals.io/message/20321#20333 · In reply to: #20332 > This one's a bit more annoying than usual ;) > > It will basically break application that depends on the Date package > (eg. most of my code as DataObjects uses it internally).. Do we really > need another barrier to upgrade to 5.*? Yeah indeed, now I'll have a heap of a time when my customers want to upgrade to PHP 5.1, I find it a bit odd to have this kind of breakage ... didn't we have similar situation with PEAR::File and the SPL::File ? Which was later renamed to FileObject so both could happily live side by side ? (or is my memory failing me) IMHO this should be rolled back in .1 and only introduced in PHP 6 (on by default) Rasmus mentioned that no PEAR person tested the final RC and all that and thus this issue wasn't found ... Correct me if I'm wrong, but wasn't that change done between the final RC and the official release ? Regards Helgi --- ## #20335 — Lester Caine — 2005-11-25T07:49:03+00:00 URL: https://externals.io/message/20321#20335 · In reply to: #20330 Rasmus Lerdorf wrote: > 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. Rasmus - the main problem here is that there is *TOO* much going on with PHP and while everything can be justified it is just adding to the *NON* take up of PHP5! PHP5 needs a *STABLE* code base so we can convince people that PHP4 is dead and stop adding functionality to that. At the same time many of us need PHP6 *NOW* just for the Unicode stuff. There are too many cooks at the moment, so many of us who used to download a new version and run it have switched off. I do not plan to run 5.1 in production because I've only JUST got 5.0.5 stable and I don't want yet another round of tweaking hidden bugs ( I use my OWN date/time stuff ! ). I'll wait for PHP6 now before I switch again since PHP5.0.5 is stable for me !!! and if users want to use my code with the latest PHP4.4 they can fix the pigging bugs themselves :) The one thing that needs to happen is a roadmap that actually plans a single stable code base that we can all use in production and that does not tread on everybody elses toes with every release. Has *NOBODY* learnt that "It was wrong so we fixed it" is only acceptable if there is a clean path to advising users how to fix things and not simply hide all the now broken code behind messages? While plowing forward in an attempt to add lots of extra wiz bang features Microsoft like may seem essential, we end up with the same problems - how many people still use W95 ;) Rather than work on a PHP4 fork, how about a means of converting PHP4 code so it will work on PHP5, and when something needs fixing in PHP5 check and warn rather than break? If you want more of us to test RC's you need to restore confidence that it's worth the effort :( -- Lester Caine ----------------------------- L.S.Caine Electronic Services Treasurer - Firebird Foundation Inc. --- ## #20336 — Rasmus Lerdorf — 2005-11-25T08:03:35+00:00 URL: https://externals.io/message/20321#20336 · In reply to: #20335 Lester Caine wrote: > Rather than work on a PHP4 fork, how about a means of converting PHP4 > code so it will work on PHP5, and when something needs fixing in PHP5 > check and warn rather than break? If you want more of us to test RC's > you need to restore confidence that it's worth the effort :( This particular issue has nothing to do with PHP 4. As far as everyone agreeing on a single release/code base. I don't see that happening. We are all on different timelines here with different requirements. I skipped PHP 5.0.x completely, for example, and will move everything to PHP 5.1 because it fit my schedule best and the performance and features in 5.1 meet my requirements. You decided on PHP 5.0.5. And we are not a software company building software for our customers here. We are all customers who happen to have similar requirements and collaborate, for better or worse, on a unified approach to meeting these requirements. As these requirements diverge with the larger customer-base it becomes harder and harder to coordinate, but I don't see how we can massage the situation to get everyone on the same page without alienating pretty much everyone. We have to find the balance between meeting the stability requirements for the customers who are perfectly happy with the featureset in PHP 4.x and don't want anything to change, the folks who want the simpler XML handling, SOAP and stronger OO in PHP 5 and then the group that need full Unicode support yesterday. We have a proposed roadmap for PHP 6 in terms of features and changes. There are no dates on that roadmap because frankly that is impossible to do in a project like this. -Rasmus --- ## #20337 — Marcus Boerger — 2005-11-25T08:16:48+00:00 URL: https://externals.io/message/20321#20337 · In reply to: #20333 Hello Helgi, obviously one problem is that PEAR does ignore coding standards. Classes should be prefixed in both pear and core. And neither Date nor File is in any way prefixed. In th end all we see here is that we want namespaces asap. One thing to discuss now is whether we want to put out 5.1.1 or even 5.1.0pl1 asap with Date in ext/Date renamed to something diferent. best regards marcus Friday, November 25, 2005, 8:40:47 AM, you wrote: > > > […] > Yeah indeed, now I'll have a heap of a time when my customers want to > upgrade to PHP 5.1, I find it a bit odd to have this kind of breakage ... > didn't we have similar situation with PEAR::File and the SPL::File ? Which > was later renamed to FileObject so both could happily live side by side ? > (or is my memory failing me) > IMHO this should be rolled back in .1 and only introduced in PHP 6 (on by > default) > Rasmus mentioned that no PEAR person tested the final RC and all that and > thus this issue wasn't found ... Correct me if I'm wrong, but wasn't that > change done between the final RC and the official release ? > Regards > Helgi Best regards, Marcus --- ## #20338 — Lester Caine — 2005-11-25T08:20:45+00:00 URL: https://externals.io/message/20321#20338 · In reply to: #20336 Rasmus Lerdorf wrote: > We have to find the balance > between meeting the stability requirements for the customers who are > perfectly happy with the featureset in PHP 4.x and don't want anything > to change, the folks who want the simpler XML handling, SOAP and > stronger OO in PHP 5 and then the group that need full Unicode support > yesterday. I'd be happy with that if the same people who claim to be happy with PHP4 did not complain when code I've produced for PHP5 and provide open sourced does not run for them - even given that most of the Firebird stuff was never back ported to PHP4 anyway! (Which is why I've never used PHP4 in production either) > We have a proposed roadmap for PHP 6 in terms of features and changes. > There are no dates on that roadmap because frankly that is impossible to > do in a project like this. That is one I am following with interest, and I have a large archive of unicode data ready to apply to the results :) But *PLEASE* can we have windows builds to play with from time to time ;) Some of us still do not have the tools to build one ourselves :( -- Lester Caine ----------------------------- L.S.Caine Electronic Services Treasurer - Firebird Foundation Inc. --- ## #20340 — Pierre — 2005-11-25T08:25:30+00:00 URL: https://externals.io/message/20321#20340 On Thu, 24 Nov 2005 23:45:45 -0800 rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > Helgi Þormar wrote: > > […] > > Nope, this change was in RC6: > > 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 > > I missed it too, but then I don't use pear/Date anywhere. It is not only about date, such changes in 5.1 are the worst idea we can have, and doing so late in the release process is even worst. Wez and you told me that I do propose solutions, for the 5.1 release, I see 2 possibilities: 1) Drop this 5.1.0 release and repack everything without the class date 2) Release 5.1.0pl1 as soon as possible to fix the problem 1) is, as far as I know, not possible, so we have to go with 2). Marcus, arguing such way is missing the minimum informations one may need to comment this problem. Can you seriously think that adding such class in a minor release is the way to go? What is obvious is that there is not enough people having a real influence on what should go in or what should not go. As a reminder, the last releases with such non obvious breaks was our last two... I let you wonder who wrote the fix. About ext/date, it was a bad idea from day #1 to do it this way. I proposed to add a new date/time APIs in php5 before it was even available, a 1st proposal was done and the 1st codebase was commited in pecl (where all new codes should first go for tests and approbations). I asked for feedbacks and for people willing to help to define a clean api and how it should work (both for OO and procedural). Then Derick asked me to stop to work on this extension until he is ready with the rewrite of strtotime with a new TZ, it was his only idea, for what he said. We first agreed first to do nothing in 5.1, it was too late as 5.1 was already in a bug fixes only period, who cares? he commited and replace strtotime... Then comes the replacement of `date()` and some other functions, and now the addition of a date """object""". Can we really say it is a mistake? a lack of attention from QA people? from users? from PEAR? I do not think so. --Pierre --- ## #20341 — Jessie Hernandez — 2005-11-25T08:26:22+00:00 URL: https://externals.io/message/20321#20341 · In reply to: #20337 Marcus, I have good news on this (I added both constants and function support!). I will post the patch soon. There are still a few things that need to be discussed, but right now the functionality is a huge step forward. Best regards, Jessie Marcus Boerger wrote: > Hello Helgi, > > obviously one problem is that PEAR does ignore coding standards. Classes > should be prefixed in both pear and core. And neither Date nor File is in > any way prefixed. In th end all we see here is that we want namespaces asap. > > One thing to discuss now is whether we want to put out 5.1.1 or even > 5.1.0pl1 asap with Date in ext/Date renamed to something diferent. > > best regards > marcus > > Friday, November 25, 2005, 8:40:47 AM, you wrote: > > > > […] > > > > […] > > > > […] > > > > […] > > > > […] > > > > […] > > > > > > Best regards, > Marcus --- ## #20344 — Lukas Smith — 2005-11-25T08:41:46+00:00 URL: https://externals.io/message/20321#20344 · In reply to: #20337 Marcus Boerger wrote: > obviously one problem is that PEAR does ignore coding standards. Classes > should be prefixed in both pear and core. And neither Date nor File is in > any way prefixed. In th end all we see here is that we want namespaces asap. Err, how are we supposed to prefix PEAR::Date? PEAR_Date? Date_Date? Lala_Date? I guess only the first one is somewhat valid proposal. Anyways it makes absolute sense to use the best most clear class names when we add functionality currently missing in PHP. Just as well it makes sense for php core to do the same thing. The problem is just that PEAR is not part of the php development cycle. So whatever API we come up with is totally ignored by php core. This may be because the PEAR API sucks. It may also be caused by the fact that usually our implementation will probably be written for a previous PHP version. In a perfect world we would define an API, implement it in PEAR as a testbed for interest and if we find its popular and there are significant performance improvements to expect from an implementation in C we take that API and implement it in C. However I do not see this happening ever. So I do not see a point in PEAR packages claiming away nice and clear names from php core. We should either cooperate on the API level or just have php core superseed PEAR stuff. PEAR then goes and fixes whatever breakage occurs. What however would be nice is some advance notice. And where is the entry in the upgrading guide? Oh and for the record if there is a PEAR class by the name of Date you can be sure that there is a class by the name of Date as well. So in conclusion its needlessly messy. I am sure other projects than PEAR also have a Date class. Maybe we need to teach our users (including PEAR) that they should simply stick to prefixing everything with 3-4 letter combinations (maybe even offer a central place to register them, like we should do in the PEAR channel listing - http://pear.php.net/channels/). regards, Lukas --- ## #20345 — Marcus Boerger — 2005-11-25T09:09:20+00:00 URL: https://externals.io/message/20321#20345 · In reply to: #20344 Hello Lukas, Friday, November 25, 2005, 9:41:46 AM, you wrote: > Marcus Boerger wrote: > > […] > Err, how are we supposed to prefix PEAR::Date? > PEAR_Date? > Date_Date? > Lala_Date? > I guess only the first one is somewhat valid proposal. > Anyways it makes absolute sense to use the best most clear class names > when we add functionality currently missing in PHP. Just as well it > makes sense for php core to do the same thing. > The problem is just that PEAR is not part of the php development cycle. > So whatever API we come up with is totally ignored by php core. This may > be because the PEAR API sucks. It may also be caused by the fact that > usually our implementation will probably be written for a previous PHP > version. > In a perfect world we would define an API, implement it in PEAR as a > testbed for interest and if we find its popular and there are > significant performance improvements to expect from an implementation in > C we take that API and implement it in C. > However I do not see this happening ever. So I do not see a point in > PEAR packages claiming away nice and clear names from php core. We > should either cooperate on the API level or just have php core superseed > PEAR stuff. > PEAR then goes and fixes whatever breakage occurs. What however would be > nice is some advance notice. And where is the entry in the upgrading > guide? Oh and for the record if there is a PEAR class by the name of > Date you can be sure that there is a class by the name of Date as well. > So in conclusion its needlessly messy. I am sure other projects than > PEAR also have a Date class. Maybe we need to teach our users (including > PEAR) that they should simply stick to prefixing everything with 3-4 > letter combinations (maybe even offer a central place to register them, > like we should do in the PEAR channel listing - > http://pear.php.net/channels/). That conclusion means stay with date in ext/date and have pear learn the lesson by making the same mistake in core. Once again the only solution is namespacing. Best regards, Marcus --- ## #20346 — Lukas Smith — 2005-11-25T09:13:42+00:00 URL: https://externals.io/message/20321#20346 · In reply to: #20345 Marcus Boerger wrote: > > […] > > > That conclusion means stay with date in ext/date and have pear learn the > lesson by making the same mistake in core. Once again the only solution is > namespacing. indeed. though this "mistake" applies to all of PEAR at this point .. it effectively means we need to fix _all_ of PEAR (which might be the point where you start of from scratch, php5 only etc .. but this is a topic for the pear mailinglists) regards, Lukas --- ## #20348 — Derick Rethans — 2005-11-25T09:49:24+00:00 URL: https://externals.io/message/20321#20348 · In reply to: #20337 > Hello Helgi, > > obviously one problem is that PEAR does ignore coding standards. Classes > should be prefixed in both pear and core. And neither Date nor File is in > any way prefixed. In th end all we see here is that we want namespaces asap. > > One thing to discuss now is whether we want to put out 5.1.1 or even > 5.1.0pl1 asap with Date in ext/Date renamed to something diferent. No, as this breaks backwards compability. I have code written for this and that is going to be released. If the class constants are removed, you will break code that is out there. There were similar reasons why Wez didn't want to change the odd PDO method because people were running it production while PDO was not even beta - which is fine. But you can definitely not change code in a released version. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #20351 — Pierre — 2005-11-25T09:55:59+00:00 URL: https://externals.io/message/20321#20351 · In reply to: #20348 On Fri, 25 Nov 2005 10:49:24 +0100 (CET) derick@php.net (Derick Rethans) wrote: > > > > […] > > No, as this breaks backwards compability. I have code written for > this and that is going to be released. If the class constants are > removed, you will break code that is out there. There were similar > reasons why Wez didn't want to change the odd PDO method because > people were running it production while PDO was not even beta - which > is fine. But you can definitely not change code in a released version. I think you are either kidding or living in a dream. You keep doing what you want, do not inform us about what you do (and do not say anything in commit messages). This release is a mistake and again you are responsible for that. Assume your wrong decisions once. --Pierre --- ## #20352 — Sebastian Kugler — 2005-11-25T10:02:02+00:00 URL: https://externals.io/message/20321#20352 · In reply to: #20348 Derick, > you will break code that is out there. do you have an idea how much code is "out there" that has classes named "Date"? > But you can > definitely not change code in a released version. Above all, you can definitely not introduce new classes in RC6! And this date class doesn't even seem to provide any functionality, so that there would be an incentive (or even possibility) to migrate projects using PEAR::Date to the new Date class. Why did this class have to be crippled (i. e. deactivating its methods) BUT incorporated in 5.1 and why not before RC6? -- Sebastian --- ## #20358 — Christian Schneider — 2005-11-25T10:11:33+00:00 URL: https://externals.io/message/20321#20358 · In reply to: #20346 Lukas Smith wrote: > Marcus Boerger wrote: > > […] > > indeed. > though this "mistake" applies to all of PEAR at this point .. As has been pointed out before this isn't only a PEAR problem: Every single application out there defining a Date class has to be changed if the core adds a class with the same name. Is this common? One of our running gags here is that every project ends up adding its own set of date formating/conversion functions/classes at some point. So unless people are prefixing all local classes there is a rather good chance of having a class named Date in quite some projects. Section [7] of CODING_STANDARDS Naming Conventions states that "The class name should be prefixed with the name of the 'parent set'" but at the same time lists "Curl" as good. Now my question is whether the prefixing should be enforced (at least when a common name like Date is used)? Or a) am I missing something b) is it the core developers' opinion that core classes have the right of way? - Chris --- ## #20354 — Sascha Schumann — 2005-11-25T10:20:53+00:00 URL: https://externals.io/message/20321#20354 · In reply to: #20348 > No, as this breaks backwards compability. I have code written for this > and that is going to be released. If the class constants are removed, > you will break code that is out there. There were similar reasons why > Wez didn't want to change the odd PDO method because people were running > it production while PDO was not even beta - which is fine. But you can > definitely not change code in a released version. Derick, the Date class is in "a released version" because you sneaked it in through the backdoor. Activating a class in the final RC was obviously wrong and you are very well aware of the fact. Don't try to cover up now. - Sascha --- ## #20359 — Derick Rethans — 2005-11-25T10:37:02+00:00 URL: https://externals.io/message/20321#20359 · In reply to: #20354 > > […] > > Derick, the Date class is in "a released version" because you > sneaked it in through the backdoor. Activating a class in > the final RC was obviously wrong and you are very well aware > of the fact. Don't try to cover up now. It's definitely not the most elegant way, I agree there. But there was also no sneaking as it was discussed months before, and it was actually Ilia who suggested doing it in PHP 5.1.0 and not 5.1.1. This code has been in CVS for about 5 months, but people didn't want to have it enabled as they didn't want to stall the release. The idea was to put it into 5.1.1 then. That is fine, but I think it's not fair to blame me for not having being allowed to put my code in there and thus creating the current problems. Besides that, using "Date" and "Timezone" as classnames are the most sensible names for those classes and I do not think we should have change that. regards, Derick --- ## #20360 — Derick Rethans — 2005-11-25T10:43:17+00:00 URL: https://externals.io/message/20321#20360 · In reply to: #20352 > Derick, > > > […] > > do you have an idea how much code is "out there" that has classes > named "Date"? No, I have no numbers, but there are definitely people who used that name out there (besides PEAR). PHP 5.1 does come with other changes in behavior though, which are all meant in the upgrade notes. Included here is the issue with the date class. (I know this only works in an ideal world:) Users should always evaluate if they can upgrade to the latest PHP version (x. or .y.) to see if there is any change in behavior, therefore it shouldn't be that much of a problem for people writing good applications. ISPs should know better than to upgrade immediately. > Above all, you can definitely not introduce new classes in RC6! It was oversighted, it should indeed have been done before rc1 (or rc2). > And this date class doesn't even seem to provide any functionality, so > that there would be an incentive (or even possibility) to migrate > projects using PEAR::Date to the new Date class. Why did this class > have to be crippled (i. e. deactivating its methods) BUT incorporated > in 5.1 and why not before RC6? It has class constants, so there is (some) functionality. Previously the constants were "DATE_ISO8601" and now they are date::ISO8601, this is something that I use in my code currently - this code is about to be released to the public. And if it was for me, this class *would* have had functionality and it has been ifdef'ed out in CVS for about 5 months now because it could stall the release. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #20362 — Sascha Schumann — 2005-11-25T10:49:50+00:00 URL: https://externals.io/message/20321#20362 · In reply to: #20359 > It's definitely not the most elegant way, I agree there. But there was > also no sneaking as it was discussed months before, and it was actually > Ilia who suggested doing it in PHP 5.1.0 and not 5.1.1. Then I have to ask both of you: why is there no mentioning in the release notes or the upgrading guide regarding "Date" being reserved for PHP now? The language/base library might want to reserve certain simple classnames for itself. That is its right. But: Doing so in a minor release is absolutely bad timing. It gets worde because there apparently has been _no_ documentation of the fact at all. How shall our users prepare themselves appropiately? I move that the class is renamed for the time being as to not conflict with existing codebases, and release 5.1.1 expediently. - Sascha --- Next page: https://externals.io/message/20321.md?page=2