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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
