Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » New Datetime class problem »

New Datetime class problem

php.internals

Mauro Nicolás Infantino

19 years ago
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.

Rasmus Lerdorf

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

Ilia A.

19 years ago
On 3-Nov-06, at 3:01 PM, 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). 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.

Christian Schneider

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

Ilia A.

19 years ago
On 4-Nov-06, at 11:18 AM, Christian Schneider wrote:
> 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).
Translation: blame other people...
>> 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 ;-)
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.
>> 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.
You can use old PHP too, or modify the source code, it is "open source" after-all. Ilia Alshanetsky

Christian Schneider

19 years ago
Ilia Alshanetsky wrote:
> On 4-Nov-06, at 11:18 AM, Christian Schneider wrote: >> 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). > > 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

Marcus Börger

19 years ago
Hello Christian, Sunday, November 5, 2006, 5:21:24 AM, you wrote:
> Ilia Alshanetsky wrote: >> On 4-Nov-06, at 11:18 AM, Christian Schneider wrote: >>> Ilia Alshanetsky wrote: >> 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.
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

Christian Schneider

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

Kevin Waterson

19 years ago
This one time, at band camp, Christian Schneider <cschneid@cschneid.com> 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."

Ron Korving

19 years ago
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" <cschneid@cschneid.com> wrote in message news:454D6EDE.60202@cschneid.com...
> 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?

Lukas Smith

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

Ilia A.

19 years ago
On 4-Nov-06, at 11:55 PM, Christian Schneider wrote:
> 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

Christian Schneider

19 years ago
Ilia Alshanetsky wrote:
> On 4-Nov-06, at 11:55 PM, Christian Schneider wrote: > >> But my favourite solution would be to >> a) have namespaces handling this issue > > Not happening in 5.2 branch.
I know. I'm talking about a long term solution.
>> b) not introducing (many) more core classes before that > > They will continue to be introduced as needs for them appear.
Sure, I don't doubt that. I'm just describing my favourite scenario.
>> 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.
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

Ilia A.

19 years ago
On 5-Nov-06, at 12:59 PM, Christian Schneider wrote:
> >>> 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. > > 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

Ilia A.

19 years ago
On 4-Nov-06, at 11:21 PM, Christian Schneider wrote:
> Ilia Alshanetsky wrote: >> On 4-Nov-06, at 11:18 AM, Christian Schneider wrote: >>> 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). >> 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.
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.
>> s 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?
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.
>> 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.
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

Lester Caine

19 years ago
( This should have been to the pigging list !!!! sorry Ilia ) Ilia Alshanetsky wrote:
>>> 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. > > 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

Marcus Börger

19 years ago
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:
>>>> 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. >> >> 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
Best regards, Marcus

Christian Schneider

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

Ilia A.

19 years ago
On 5-Nov-06, at 1:13 PM, Christian Schneider wrote:
> 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...
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

Christian Schneider

19 years ago
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...
>> 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.
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.
>> 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.
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

Ilia A.

19 years ago
On 5-Nov-06, at 12:48 PM, Christian Schneider wrote:
> 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...
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.
>>> 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. > > 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. > >>> 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. > > 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

Lester Caine

19 years ago
Ilia Alshanetsky wrote:
> 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.
I never used the PEAR Date - it was crap - but all my applications failed with your new one BECAUSE Date was the obvious name for that package. I STILL can not see why we can't just select these things as I do in C++ and include your new function if I want or keep with my own established version - what ever the name. This new stuff does not HAVE to be hard coded into the core - simply loadable like any other good extensible language? If we don't want it we don't load it! I don't need any database stuff other than Firebird - therefore I want a DATE and TIME package that follows Firebird rules end of story.
-- 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

Pierre Joye

19 years ago
Hello, On 11/6/06, Lester Caine <lester@lsces.co.uk> wrote:
> Ilia Alshanetsky wrote: > > > 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.
For the 10^347 times, the problem was/is not Date but the way global namespace and features got in late in the game, without previous warning in any previous PHP release or any announcements. The problem is that we just considered that we can do it whenever we want and how we want, that is the horrible mistake. Things are however getting better, at least for a limited amount of developers who have to justify/explain/change the names they use in their extensions. It will be perfect if this rule applies to anyone and the naming decisions are done before the extension/addition is in a release (RC or final). --Pierre

Ilia A.

19 years ago
On 5-Nov-06, at 6:30 PM, Lester Caine wrote:
> Ilia Alshanetsky wrote: > >> 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. > > I never used the PEAR Date - it was crap - but all my applications > failed with your new one BECAUSE Date was the obvious name for that > package. I STILL can not see why we can't just select these things > as I do in C++ and include your new function if I want or keep with > my own established version - what ever the name. This new stuff > does not HAVE to be hard coded into the core - simply loadable like > any other good extensible language? If we don't want it we don't > load it! I don't need any database stuff other than Firebird - > therefore I want a DATE and TIME package that follows Firebird > rules end of story.
You seem to be under the assumption that people care about what it is that you want, reality is that most people could care less. That said this is an open source project, so rather then pointless whining on the list you can always tweak the source code to your needs, such is the beauty of the open source software. Ilia Alshanetsky

Richard Lynch

19 years ago
It seems like the history of every language goes through this... Some solve it cleanly, from the beginning with a Documented Feature: If I had a time machine, way more brains and C skill, and could waylay Rasmus back in 1995/1996, you'd have something like: The PHP_* name space is reserved for Core PHP Features. Then everybody would know that the internal PHP Date object was gonna be PHP_Date, and nobody would be dumb enough to use that in their app. code, and if they were dumb enough, you'd point to the docs. As it stands now, you'd almost want to MD5() all your class names in a code generation phase, just to be safe :-v
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?