Pierre wrote: > On Sat, 26 Nov 2005 00:50:04 -0600 > [EMAIL PROTECTED] (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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
