Re: Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)

John Coggeshall wrote:

On Tue, 2006-07-18 at 18:58 -0700, Rasmus Lerdorf wrote:

Regardless, we know it's coming and we know it'll have namespacing support. If we do PHPDateTime right now we'll have PHP::PHPDateTime later, and that's just wonky.

Why would it be PHP::PHPDateTime ? An extra alias here isn't going to hurt very much. We are not talking about hundreds of classes. At this point we are talking about one with a very common short name.

Perhaps it's only an assumption, but I would think that "core" PHP classes would fall into some sort of standardized namespace ala ext/standard.. be it PHP:: or STD:: or whatever... PHP::Date PHP::Dir PHP::Zip PHP::Whatever So, unless you are proposing that we call it PHPDateTime now and rename it to PHP::DateTime later you'll end up with PHP::PHPDateTime if we start prefixing things with PHP* now. If the argument is that it "makes sense" that what used to be PHPDateTime is now PHP::DateTime I'll agree, but what could have been <?php // My old PHP 5.2 script using DateTime // Make it PHP 6 compatible import PHP; class foo extends DateTime { } ?> will now be a much more painful search/replace annoyance. To me that's a huge win longterm.

Sure, but let's get some perspective as well here. We are talking about 1 class here with a naming problem that needs to bridge the gap between 5.x and 6.x at this point. We are not going to be adding dozens of new internal classes before 6. We may very well be able to just call it DateTime and be done with it. Calling it Date will mess up existing installs since it would force them to upgrade PEAR which we know will be a hurdle for many and I don't really think DateTime is in any way a worse name than Date since the code does way more than just handle dates. -Rasmus