# New Datetime class problem - Thread: https://externals.io/message/26311 - Original archive: https://news-web.php.net/php.internals/26311 - Started by Mauro N. Infantino on 2006-11-03T20:01:48+00:00 - Messages: 30 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/26311.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 --- ## #26311 — Mauro N. Infantino — 2006-11-03T20:01:48+00:00 URL: https://externals.io/message/26311#26311 Hi all, In our current codebase for PHP5.1 we've a class named 'Datetime' (I suppose a lot of people is in the same situation). I'm wondering if there's any chance to add an ini directive in order to disable the definition of the new class. I mean, we had a lot of PHP4 projects and, with two or three minor changes we got them working in PHP5 (as a matter of fact, we didn't experience almost any BC trouble... It was kind of easy). How could it be more difficult to upgrade from PHP5.1 to PHP5.2? It would be a nightmare too change every date creation, and, of course, the type hints. I'd really like to move to PHP5.2 because it has a lot of really nice things. Thanks. Regards, Mauro. --- ## #26312 — Rasmus Lerdorf — 2006-11-03T20:06:44+00:00 URL: https://externals.io/message/26311#26312 · In reply to: #26311 Mauro N. Infantino wrote: > Hi all, > > In our current codebase for PHP5.1 we've a class named 'Datetime' (I suppose > > a lot of people is in the same situation). More people had one named Date, so we changed it from Date to DateTime. You are going to have to change yours. Sorry. -Rasmus --- ## #26313 — Ilia Alshanetsky — 2006-11-03T20:14:43+00:00 URL: https://externals.io/message/26311#26313 · In reply to: #26311 > Hi all, > > In our current codebase for PHP5.1 we've a class named > 'Datetime' (I suppose > > a lot of people is in the same situation). I'm wondering if there's > any > chance > to add an ini directive in order to disable the definition of the > new class. Nil to none. > I mean, we had a lot of PHP4 projects and, with two or three minor > changes > we > got them working in PHP5 (as a matter of fact, we didn't experience > almost > any > BC trouble... It was kind of easy). How could it be more difficult to > upgrade > from PHP5.1 to PHP5.2? It would be a nightmare too change every date > creation, > and, of course, the type hints. I'd really like to move to PHP5.2 > because it > > has a lot of really nice things. Avoid common namespaces and you'll make your application futureproof. When developing a distributed application it is always a good idea to prefix functions/class names with app name or some acronym to avoid overly long names. The way things are going you are going to see more and more classes being introduced by "core" PHP as well as the growing number of PECL extensions out there and I am not even going to mention the thousands of libraries out there. Ilia Alshanetsky P.S. If you absolutely must disable it, edit the source code and rename the native class to DateTime2 or something similar. --- ## #26323 — Christian Schneider — 2006-11-04T16:18:45+00:00 URL: https://externals.io/message/26311#26323 · In reply to: #26313 Ilia Alshanetsky wrote: > Avoid common namespaces and you'll make your application futureproof. I'm still wary of this approach because it puts the burden on 99% of the code to be written (applications) instead of a small, controllable subset (core and libraries). > When developing a distributed application it is always a good idea to > prefix functions/class names with app name or some acronym to avoid > overly long names. The way things are going you are going to see more > and more classes being introduced by "core" PHP as well as the growing ... which brings us back to the discussion of namespaces and which one core classes should use ;-) > number of PECL extensions out there and I am not even going to mention > the thousands of libraries out there. Those are less of a problem because you don't have to include them if you don't want to. - Chris --- ## #26325 — Ilia Alshanetsky — 2006-11-04T18:34:55+00:00 URL: https://externals.io/message/26311#26325 · In reply to: #26323 > Ilia Alshanetsky wrote: > > […] > > I'm still wary of this approach because it puts the burden on 99% > of the code to be written (applications) instead of a small, > controllable subset (core and libraries). Translation: blame other people... > > […] > > ... which brings us back to the discussion of namespaces and which > one core classes should use ;-) The language should ALWAYS have the best names possible to simplify development, because that means convenience for majority of users. No matter how popular your app, PHP, the language is still hundreds if not thousands of times more popular and as such needs of many outweigh needs of the few. > > […] > > Those are less of a problem because you don't have to include them > if you don't want to. You can use old PHP too, or modify the source code, it is "open source" after-all. Ilia Alshanetsky --- ## #26331 — Christian Schneider — 2006-11-05T04:21:24+00:00 URL: https://externals.io/message/26311#26331 · In reply to: #26325 Ilia Alshanetsky wrote: > > > […] > > Translation: blame other people... I'm not sure what you mean here. I was just doing a head count on who has to come up with save names: A few core developers or all of the PHP users. > The language should ALWAYS have the best names possible to simplify > development, because that means convenience for majority of users. No While that's certainly true (and part of me is even thinking it is the right approach) it means that each and everyone writing PHP code (which means a big number of people with all different levels of experience) has to care about naming. So it makes the language a little less simple to use. That's all I'm saying. > matter how popular your app, PHP, the language is still hundreds if not > thousands of times more popular and as such needs of many outweigh needs > of the few. A little thought experiment: Let's assume the number of application classes (and the usage of those classes) is on average higher than those of the core classes. Would that change the situation? > You can use old PHP too, or modify the source code, it is "open source" > after-all. Come on, that can't be the solution. Think about hosting companies for example. Don't get me wrong: I'm not saying you're wrong, I'm just trying to provide another point of view on the topic here which should be considered IMHO. - Chris --- ## #26332 — Marcus Boerger — 2006-11-05T04:39:13+00:00 URL: https://externals.io/message/26311#26332 · In reply to: #26331 Hello Christian, Sunday, November 5, 2006, 5:21:24 AM, you wrote: > Ilia Alshanetsky wrote: > > […] > While that's certainly true (and part of me is even thinking it is the > right approach) it means that each and everyone writing PHP code (which > means a big number of people with all different levels of experience) > has to care about naming. So it makes the language a little less simple > to use. That's all I'm saying. We had problems with Date, DateTime and Time as all of those are common. Should we name a class that represents data and time info name after say 'PhpDateTimeFart' so that there is no problem? Because if you think further it might be commone to put Php into class names that deal with php... that said wouldn't it be easier for the masses of people, that start using PHP, to not having to read the manual each time a date time class is being used? just my small thought on this Best regards, Marcus --- ## #26334 — Kevin Waterson — 2006-11-05T04:43:49+00:00 URL: https://externals.io/message/26311#26334 · In reply to: #26333 This one time, at band camp, Christian Schneider wrote: > But my favourite solution would be to > a) have namespaces handling this issue So, we've come full circle. PHP does not support namespaces, so you should be prefixing. Kevin -- "Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote." --- ## #26333 — Christian Schneider — 2006-11-05T04:55:58+00:00 URL: https://externals.io/message/26311#26333 · In reply to: #26332 Marcus Boerger wrote: > We had problems with Date, DateTime and Time as all of those are common. I'm well aware of this and the discussion around it. > Should we name a class that represents data and time info name after say > 'PhpDateTimeFart' so that there is no problem? Because if you think further > it might be commone to put Php into class names that deal with php... that > said wouldn't it be easier for the masses of people, that start using PHP, > to not having to read the manual each time a date time class is being used? I'm willing to bet that the number of PhpDate classes out there is considerably smaller then the number of Date classes. [ You could theoretically even add an `E_STRICT` (or `E_DEPRECATED` ;-)) warning if class names starting with Php are used. ] But my favourite solution would be to a) have namespaces handling this issue b) not introducing (many) more core classes before that c) and thus not having to educate users to use prefixes (to have less guidelines is a Good Thing(tm) IMHO) I didn't want to restart the whole naming discussion really but point is that it is still an open issue for the next (major) release and should better be looked at sooner than later. - Chris --- ## #26338 — Ron Korving — 2006-11-05T11:33:11+00:00 URL: https://externals.io/message/26311#26338 · In reply to: #26333 You can't rely on people prefixing their classes. In libraries, yes, but in applications, don't count on it too much. - First of all, people use their classes a lot more than PHP core classes, and so prefixing application classes is a big burden compared to prefixing PHP core classes. - Second, with the active record design pattern becoming more popular, database table-names are starting to dictate class names. But I'm not saying PHP core classes should be prefixed. I think there's only one real solution, which is the usage of namespaces, and I'm eagerly awaiting their arrival in PHP. You can't educate the whole world into using prefixes, because people simply won't listen and will be stubborn. It just won't happen. The FUD is in not knowing what classes will be added next and if the user's project will suffer from it. I think these stubborn users are right (so I guess that makes me a stubborn user). With namespaces this problem would not even exist, and so it's PHP that needs to change, not the user approach. -- Ron "Christian Schneider" wrote in message news:454D6EDE.60202@cschneid.com... > Marcus Boerger wrote: > > […] > > I'm well aware of this and the discussion around it. > > > […] further > > […] that > > […] PHP, > > […] used? > > I'm willing to bet that the number of PhpDate classes out there is > considerably smaller then the number of Date classes. > [ You could theoretically even add an `E_STRICT` (or `E_DEPRECATED` ;-)) > warning if class names starting with Php are used. ] > > But my favourite solution would be to > a) have namespaces handling this issue > b) not introducing (many) more core classes before that > c) and thus not having to educate users to use prefixes (to have less > guidelines is a Good Thing(tm) IMHO) > > I didn't want to restart the whole naming discussion really but point is > that it is still an open issue for the next (major) release and should > better be looked at sooner than later. > > - Chris --- ## #26339 — Lukas Kahwe Smith — 2006-11-05T11:43:39+00:00 URL: https://externals.io/message/26311#26339 · In reply to: #26338 Ron Korving wrote: > - First of all, people use their classes a lot more than PHP core classes, > and so prefixing application classes is a big burden compared to prefixing > PHP core classes. Its quite trivial .. all people need to do is stick a single underscore into their class name [1]. Thats all. They only need to really prefix with anything a bit longer if they want to avoid name clashes with other third party code. > - Second, with the active record design pattern becoming more popular, > database table-names are starting to dictate class names. Err, where is the problem applying a default prefix in that scenario? And sure if there is a sensible implementation for namespaces I am sure we will get the feature. I have not yet heared any core people say that they are against the feature in general. regards, Lukas [1] http://www.php.net/manual/en/userlandnaming.php --- ## #26344 — Ilia Alshanetsky — 2006-11-05T16:15:44+00:00 URL: https://externals.io/message/26311#26344 · In reply to: #26331 > Ilia Alshanetsky wrote: > > […] > > I'm not sure what you mean here. I was just doing a head count on > who has to come up with save names: A few core developers or all of > the PHP users. When we were picking a name the discussion was public on this very list and based on our analysis of what names people were using in their application and what would be an ideal name DateTime was picked. Google's code search confirms we've made the right decision as it would seem there are only about 8 results for applications already misusing that namespace. > > […] > > A little thought experiment: Let's assume the number of application > classes (and the usage of those classes) is on average higher than > those of the core classes. Would that change the situation? The number of current users does not matter, simply because are you not comparing equivalent things here. You are comparing existing code to something that just came out. > > […] > > Come on, that can't be the solution. Think about hosting companies > for example. They as a rule use old versions, in fact I bet you'd be hard pressed to find a big or even a medium size hosting company offering PHP 5.2 just now. So you have plenty of time to fix your code. Ilia Alshanetsky --- ## #26345 — Ilia Alshanetsky — 2006-11-05T16:17:17+00:00 URL: https://externals.io/message/26311#26345 · In reply to: #26333 > But my favourite solution would be to > a) have namespaces handling this issue Not happening in 5.2 branch. > b) not introducing (many) more core classes before that They will continue to be introduced as needs for them appear. > c) and thus not having to educate users to use prefixes (to have > less guidelines is a Good Thing(tm) IMHO) I am not even going to bother with this one. Ilia Alshanetsky --- ## #26350 — Lester Caine — 2006-11-05T17:09:54+00:00 URL: https://externals.io/message/26311#26350 · In reply to: #26344 ( This should have been to the pigging list !!!! sorry Ilia ) Ilia Alshanetsky wrote: > > […] > > They as a rule use old versions, in fact I bet you'd be hard pressed to > find a big or even a medium size hosting company offering PHP 5.2 just > now. So you have plenty of time to fix your code. The main problem here Ilia is that people HAVE to fix their code JUST IN CASE the host updates. Some people will not even know they have a problem because they are using a third party application and then they will not know how to fix it IF their host updates. Since it would seem that most hosts have not even switched to PHP5 anyway, this is probably all academic anyway, but we have been here before, with versions of PHP released that broke a large number of applications and it got to the state that host WOULD NOT update in case it broke something. DateTime is just another example of the fact that PHP has no management of conventions and these get changed version to version. We NEED a mechanism to pinch back common function names that does not break existing applications simply because the vast number of users have no knowledge that there is a problem! -- Lester Caine - G8HFL ----------------------------- L.S.Caine Electronic Services - http://home.lsces.co.uk Model Engineers Digital Workshop - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php --- ## #26353 — Christian Schneider — 2006-11-05T17:48:10+00:00 URL: https://externals.io/message/26311#26353 · In reply to: #26344 Ilia Alshanetsky wrote: > When we were picking a name the discussion was public on this very list > and based on our analysis of what names people were using in their > application and what would be an ideal name DateTime was picked. I'm not questioning this decision. I'm talking about the policy for further classes. Maybe I should change the topic to be clearer... > > […] > > The number of current users does not matter, simply because are you not > comparing equivalent things here. You are comparing existing code to > something that just came out. Forget about all the code out there: Let's say the average application uses its own classes 10 times and PHP core classes only 5 times, which one should have the right to the short and more convenient name? And I'm not saying that this is the case, it's just a thought. > > […] > > They as a rule use old versions, in fact I bet you'd be hard pressed to > find a big or even a medium size hosting company offering PHP 5.2 just > now. So you have plenty of time to fix your code. I could be mean and ask why that is. But that's not the discussion here. We're talking about the naming policy of classes in the long run. Again: I'm not asking to change anything, I'm just mentioning that there are different point of views (PHP core centric vs. application centric ones) which both have to be recognized. - Chris --- ## #26354 — Marcus Boerger — 2006-11-05T17:57:19+00:00 URL: https://externals.io/message/26311#26354 · In reply to: #26350 Hello Lester, we have the same problem for functions since years, why is there suddenly such a big problem with classes now? All new php/pecl classes will follow one of the following rules: - Prefix with the extension name - Postfix with "Iterator" - Postfix with "Exception" that seems the same amount of protection as prefix functions with extension name plus underscore. I don't see any problem since the above rule is in place. best regards marcus Sunday, November 5, 2006, 6:09:54 PM, you wrote: > ( This should have been to the pigging list !!!! sorry Ilia ) > Ilia Alshanetsky wrote: > > […] > The main problem here Ilia is that people HAVE to fix their code JUST IN > CASE the host updates. Some people will not even know they have a > problem because they are using a third party application and then they > will not know how to fix it IF their host updates. > Since it would seem that most hosts have not even switched to PHP5 > anyway, this is probably all academic anyway, but we have been here > before, with versions of PHP released that broke a large number of > applications and it got to the state that host WOULD NOT update in case > it broke something. > DateTime is just another example of the fact that PHP has no management > of conventions and these get changed version to version. We NEED a > mechanism to pinch back common function names that does not break > existing applications simply because the vast number of users have no > knowledge that there is a problem! > -- > Lester Caine - G8HFL > ----------------------------- > L.S.Caine Electronic Services - http://home.lsces.co.uk > Model Engineers Digital Workshop - > http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ > Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php Best regards, Marcus --- ## #26355 — Ilia Alshanetsky — 2006-11-05T17:59:00+00:00 URL: https://externals.io/message/26311#26355 · In reply to: #26353 > Ilia Alshanetsky wrote: > > […] > > I'm not questioning this decision. I'm talking about the policy for > further classes. Maybe I should change the topic to be clearer... We've already established a sufficiently clear policy on this matter. When someone adds a feature to a language which is anticipated to cause BC breaks its merits are discussed on the list where all sides get a chance to expression their opinion. Once that's done developers do a quick vote and based on this vote decision is made. This is a fairly clear, simple and transparent process. > > […] > > Forget about all the code out there: Let's say the average > application uses its own classes 10 times and PHP core classes only > 5 times, which one should have the right to the short and more > convenient name? The language always has the best pick of namespaces, this is not just PHP, but ANY language. The fact we've made a compromise and allows PEAR to retain the date class IMO has been a horrible mistake, one hopefully not to be repeated in the future. > And I'm not saying that this is the case, it's just a thought. > > > […] > > I could be mean and ask why that is. But that's not the discussion > here. We're talking about the naming policy of classes in the long > run. The classes/functions/constants that will be added in the future will be based largely on the names the developers of said language components decide upon. In the event their names present issues, such as BC breaks there would be a review done to determine the merits of keeping or changing the name. It is really quite simple. Ilia Alshanetsky --- ## #26356 — Christian Schneider — 2006-11-05T17:59:12+00:00 URL: https://externals.io/message/26311#26356 · In reply to: #26345 Ilia Alshanetsky wrote: > > > > […] > > Not happening in 5.2 branch. I know. I'm talking about a long term solution. > > […] > > They will continue to be introduced as needs for them appear. Sure, I don't doubt that. I'm just describing my favourite scenario. > > […] > > I am not even going to bother with this one. So you don't think fewer rules are easier to learn and use? *puzzled* You seem to be offended by something I said. I don't know what that was but I'm apologizing anyway: I didn't mean to attack anyone here. Regards, - Chris --- ## #26358 — Ilia Alshanetsky — 2006-11-05T18:05:02+00:00 URL: https://externals.io/message/26311#26358 · In reply to: #26356 > > > […] > > So you don't think fewer rules are easier to learn and use? *puzzled* There are no "rules" there is just one rule, that's not even specific to PHP when you think of it. It is generally considered to be a good practice to prefix your code with app name or similar to avoid conflicts with other libraries and/or applications. When it comes to this rule, I think it is one of the very few that are essential for developers to learn. Ilia Alshanetsky --- ## #26360 — Christian Schneider — 2006-11-05T18:13:00+00:00 URL: https://externals.io/message/26311#26360 · In reply to: #26354 Hello Marcus, hello Ilia, now you two got me confused: Marcus Boerger wrote: > we have the same problem for functions since years, why is there suddenly > such a big problem with classes now? All new php/pecl classes will follow > one of the following rules: > - Prefix with the extension name > - Postfix with "Iterator" > - Postfix with "Exception" > that seems the same amount of protection as prefix functions with extension > name plus underscore. I don't see any problem since the above rule is in > place. This would mean classes should be prefixed by extension name... Ilia Alshanetsky wrote: > The classes/functions/constants that will be added in the future will > be based largely on the names the developers of said language > components decide upon. In the event their names present issues, such > as BC breaks there would be a review done to determine the merits of > keeping or changing the name. It is really quite simple. ... or not? - Chris --- ## #26361 — Ilia Alshanetsky — 2006-11-05T18:20:59+00:00 URL: https://externals.io/message/26311#26361 · In reply to: #26360 > Hello Marcus, hello Ilia, > now you two got me confused: > > Marcus Boerger wrote: > > […] > > This would mean classes should be prefixed by extension name... That is the common case, yes. In fact the date extension's classes follow this convention to the letter. DateTime + DateTimeZone (Date is the extension name). However, for native classes there maybe exceptions to simplify usage, when a need for such exceptions arise this will be discussed on this list. Ilia Alshanetsky --- ## #26365 — Christian Schneider — 2006-11-05T18:32:00+00:00 URL: https://externals.io/message/26311#26365 · In reply to: #26358 Ilia Alshanetsky wrote: > There are no "rules" there is just one rule, that's not even specific to > PHP when you think of it. It is generally considered to be a good > practice to prefix your code with app name or similar to avoid conflicts > with other libraries and/or applications. When it comes to this rule, I > think it is one of the very few that are essential for developers to learn. What about "do not trust user input"? Or "avoid copy/pasting code, refactor instead"? Or "use descriptive identifiers"? Those are all rules to be followed when programming. And the more there are the more experience it takes to not get any of them wrong. > > […] > > That is the common case, yes. In fact the date extension's classes > follow this convention to the letter. DateTime + DateTimeZone (Date > is the extension name). Well, almost: DateTime is a date class, not a time class. > However, for native classes there maybe exceptions to simplify usage, > when a need for such exceptions arise this will be discussed on this list. We're only talking about native classes anyway. And I think not bending the rules simplify usage more than saving a couple of letters. Wasn't that a lesson we learned from functions? - Chris --- ## #26366 — Ilia Alshanetsky — 2006-11-05T18:44:38+00:00 URL: https://externals.io/message/26311#26366 · In reply to: #26365 > Ilia Alshanetsky wrote: > > […] > > What about "do not trust user input"? Or "avoid copy/pasting code, > refactor instead"? Or "use descriptive identifiers"? Those are all > rules to be followed when programming. And the more there are the > more experience it takes to not get any of them wrong. And your point is what? There are even more rules you need to obey while driving a car, when people forget those rules they often get into accidents. Same with programing, there are rules, you can choose to ignore them, but don't complain when your code is exploited because your didn't check your input or stopped working when an namespace you've been mis-using gets taken over by the language. > > […] > > Well, almost: DateTime is a date class, not a time class. Actually it works with both date & time and calling it datedate seems rather silly. I am not going to waste more time arguing about DateTime, this has already been covered numerous time, if you got time to waste go read internals archives. > > […] > > We're only talking about native classes anyway. And I think not > bending the rules simplify usage more than saving a couple of > letters. Wasn't that a lesson we learned from functions? That's your opinion and you are certainly entitled to it, but that's just it, your opinion. Ilia Alshanetsky --- ## #26368 — Christian Schneider — 2006-11-05T18:54:18+00:00 URL: https://externals.io/message/26311#26368 · In reply to: #26366 Ilia Alshanetsky wrote: > And your point is what? There are even more rules you need to obey while My point is: Fewer rules make things easier to learn and use. > > […] > > Actually it works with both date & time and calling it datedate seems > rather silly. I am not going to waste more time arguing about DateTime, > this has already been covered numerous time, if you got time to waste go > read internals archives. It wasn't me who brought DateTime back into the discussion ;-) > > […] > > That's your opinion and you are certainly entitled to it, but that's > just it, your opinion. Thanks for finally acknowledging it. I never said it is anything more. Stop feeling offended because we have differing opinions, please, - Chris --- ## #26369 — Rasmus Lerdorf — 2006-11-05T19:28:07+00:00 URL: https://externals.io/message/26311#26369 · In reply to: #26365 Christian Schneider wrote: > Well, almost: DateTime is a date class, not a time class. Surely it handles both. A DateTime class encapsulates both date and time information. Just look at the methods like setTime() and the properties that it contains. I don't think it is badly named at all. -Rasmus --- Next page: https://externals.io/message/26311.md?page=2