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

From: Date: Wed, 19 Jul 2006 02:28:29 +0000
Subject: Re: Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
References: 1 2 3 4 5 6 7 8 9 10 11 12 13  Groups: php.internals 
Request: Send a blank email to internals+get-24627@lists.php.net to get a copy of this message
Steph Fox wrote:
Rasmus,
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.
John's right, because PHP::PHPDateTime would have to become acceptable syntax. Not the _only available_ syntax, but an acceptable one.
I don't see why that is necessarily the case. We can simply decide that it isn't.
It isn't _necessarily_ the case but how on earth are you going to treat PHPDateTime - if that's what you make people call it under PHP 5.2 - as PHP::DateTime? How are you going to cope with the inevitable duplications, assuming you work around it? And above all - why make it so f****ing complicated? Why not just have Date and later allow it to be PHP::Date or import Date? Why does it have to involve stuff that nobody in this world apart from javanuts would understand?
Because there is absolutely no reason to deliberately break our installed base for a single version when it is quite arbitrary what we call this class. We know for a fact that calling it Date will be problematic. I also don't think a single alias is very hard to figure out, but like I said, just choosing a slightly more descriptive name for the class is probably a better solution all around. -R

« previous php.internals (#24627) next »