Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » solution to the "Date" issue »

solution to the "Date" issue

php.internals

Greg Beaver

20 years ago
Hi, I would like to propose these simple steps be taken: 1) rename "date" to "PHP_Date" 2) reserve the "PHP_" prefix for all future core classes in PHP 5 (if any) 3) when namespaces become available, reserve "PHP" for all future internal classes Greg

Ken Tossell

20 years ago
Not to start a flame war, but... How about STD, Std, or something similar? It certainly works for... that language... that has multiple implementations of the standard classes. It can't hurt to play to people's comfort when the change doesn't really affect PHP in any major way. :) But yes, a standard class prefix (to be migrated to a namespace) sounds more practical than either asking everyone to use prefixes or hoping that the minimal user base is affected by a conflict. And getting everyone into a habit of importing standard php classes -- class Date extends PHP_Date {} -- might help in the future. :D Ken

Robert Cummings

20 years ago
On Fri, 2005-11-25 at 20:07, Ken Tossell wrote:
> Not to start a flame war, but... > > How about STD, Std, or something similar? It certainly works for... that > language... that has multiple implementations of the standard classes. > It can't hurt to play to people's comfort when the change doesn't really > affect PHP in any major way. :) > > But yes, a standard class prefix (to be migrated to a namespace) sounds > more practical than either asking everyone to use prefixes or hoping > that the minimal user base is affected by a conflict. > > And getting everyone into a habit of importing standard php classes -- > > class Date extends PHP_Date {}
Maybe go with proper CamelCase: class Date extends PhpDate{} :) Cheers, Rob.
-- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'

Stefan Walk

20 years ago
On 26/11/05, Robert Cummings <robert@interjinn.com> wrote:
> On Fri, 2005-11-25 at 20:07, Ken Tossell wrote: > > Not to start a flame war, but... > > > > How about STD, Std, or something similar? It certainly works for... that > > language... that has multiple implementations of the standard classes. > > It can't hurt to play to people's comfort when the change doesn't really > > affect PHP in any major way. :) > > > > But yes, a standard class prefix (to be migrated to a namespace) sounds > > more practical than either asking everyone to use prefixes or hoping > > that the minimal user base is affected by a conflict. > > > > And getting everyone into a habit of importing standard php classes -- > > > > class Date extends PHP_Date {} > > Maybe go with proper CamelCase: > > class Date extends PhpDate{} > > :)
This violates the coding standards for class names. Words have to be separated by underscores. Regards, Stefan

Marcus Börger

20 years ago
Hello Stefan, Saturday, November 26, 2005, 9:21:07 AM, you wrote:
> On 26/11/05, Robert Cummings <robert@interjinn.com> wrote: >> On Fri, 2005-11-25 at 20:07, Ken Tossell wrote: >> > Not to start a flame war, but... >> > >> > How about STD, Std, or something similar? It certainly works for... that >> > language... that has multiple implementations of the standard classes. >> > It can't hurt to play to people's comfort when the change doesn't really >> > affect PHP in any major way. :) >> > >> > But yes, a standard class prefix (to be migrated to a namespace) sounds >> > more practical than either asking everyone to use prefixes or hoping >> > that the minimal user base is affected by a conflict. >> > >> > And getting everyone into a habit of importing standard php classes -- >> > >> > class Date extends PHP_Date {} >> >> Maybe go with proper CamelCase: >> >> class Date extends PhpDate{} >> >> :)
> This violates the coding standards for class names. Words have to be > separated by underscores.
Mhhh noone updated the coding standards once we changed then before 5 was released. Right now only the __PHP_Incomplete_Class and php_user_filter plus ext MysqlI is ignoring them. The former could not be changed since there is valid code out and MysqlI not adhering to the standards caused an endless discussion...: marcus@zaphod /usr/src/php-cvs $ php -r 'print_r(get_declared_classes());'|grep _ [8] => __PHP_Incomplete_Class [9] => php_user_filter [72] => mysqli_sql_exception [73] => mysqli_driver [75] => mysqli_warning [76] => mysqli_result [77] => mysqli_stmt
> -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Best regards, Marcus

Pierre Joye

20 years ago
On Fri, 25 Nov 2005 18:32:14 -0600 cellog@php.net (Greg Beaver) wrote:
> Hi, > > I would like to propose these simple steps be taken: > > 1) rename "date" to "PHP_Date" > 2) reserve the "PHP_" prefix for all future core classes in PHP 5 (if > any) 3) when namespaces become available, reserve "PHP" for all future > internal classes
Reread the previous thread, this solution is not acceptable. The only safe solution is to put it back in the #ifdef. We have then time to do the right things and right names in php6. --Pierre

Greg Beaver

20 years ago
Pierre wrote:
> On Fri, 25 Nov 2005 18:32:14 -0600 > cellog@php.net (Greg Beaver) wrote: > > >>Hi, >> >>I would like to propose these simple steps be taken: >> >>1) rename "date" to "PHP_Date" >>2) reserve the "PHP_" prefix for all future core classes in PHP 5 (if >>any) 3) when namespaces become available, reserve "PHP" for all future >>internal classes > > > Reread the previous thread, this solution is not acceptable. > > The only safe solution is to put it back in the #ifdef. We have then > time to do the right things and right names in php6.
Pierre, you can do all the #ifdefs you want, this idea does not prevent this :). In addition, the #ifdef has no effect on this idea. Greg

Pierre Joye

20 years ago
On Sat, 26 Nov 2005 00:50:04 -0600 cellog@php.net (Greg Beaver) wrote:
> Pierre, you can do all the #ifdefs you want, this idea does not > prevent this :). In addition, the #ifdef has no effect on this idea.
You do not get the main problem. - The ifdef makes it disappear from a user point of view - The class should not even exist in the source - Nobody tested, agreed on it - 5.1 is frozen since july --Pierre

Greg Beaver

20 years ago
Pierre wrote:
> On Sat, 26 Nov 2005 00:50:04 -0600 > cellog@php.net (Greg Beaver) wrote: > > > >>Pierre, you can do all the #ifdefs you want, this idea does not >>prevent this :). In addition, the #ifdef has no effect on this idea. > > > > You do not get the main problem. > > - The ifdef makes it disappear from a user point of view > > - The class should not even exist in the source > > - Nobody tested, agreed on it > > - 5.1 is frozen since july
Pierre, I get the main problem, but I'm not sure that you do. I mean, think for one second about what you're saying: Taking the class out of PHP 5 will solve the problem for now (and I absolutely agree that this is necessary - so does *everyone* else save Derick, who is now on vacation and can't defend himself), but any time in the future it is introduced as "Date" will conflict with all existing code that has a class named "Date". #ifdef will never solve this issue. PHP code *needs* to reserve a naming area, I proposed PHP_ as a prefix for *all* new internal classes. This means that if someone comes up with a class to implement the Yertl standard as an internal class, it would be named PHP_Yertl. When namespaces come out, this will not be necessary, as we can do the same thing with the "PHP" namespace. This to me is an incontrovertible argument for namespaces: we need these to avoid PEAR's_Ridiculously_Long_Classnames. Incidentally, this is not a new concept, all constants with two underscores are explicitly reserved for internal use in the manual. Surely the fact that the class exists is a problem, but it is easily solved with #ifdef, as you said. The MAIN problem is that it is named Date, and #ifdef will never solve this problem. Greg

Pierre Joye

20 years ago
On Sat, 26 Nov 2005 14:37:39 -0600 cellog@php.net (Greg Beaver) wrote:
> Taking the class out of PHP 5 will solve the problem for now (and I > absolutely agree that this is necessary - so does *everyone* else save > Derick, who is now on vacation and can't defend himself), but any time > in the future it is introduced as "Date" will conflict with all > existing code that has a class named "Date".
Yes, anytime in the future but _not_ in 5.x and not in a RC phase, end of the topic for me. --Pierre

Derick Rethans

20 years ago
On Sat, 26 Nov 2005, Greg Beaver wrote:
> Taking the class out of PHP 5 will solve the problem for now (and I > absolutely agree that this is necessary - so does *everyone* else save > Derick, who is now on vacation and can't defend himself), but any time > in the future it is introduced as "Date" will conflict with all existing > code that has a class named "Date".
Right, and I am not going to wait (atleast) a year for PHP 6 before I can finally use my code. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org