Re: Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
| From: | Steph Fox | Date: | Wed, 19 Jul 2006 02:18:01 +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 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-24624@lists.php.net to get a copy of this message | ||
Rasmus,
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? - StephI don't see why that is necessarily the case. We can simply decide that it isn't.John's right, because PHP::PHPDateTime would have to become acceptable syntax. Not the _only available_ syntax, but an acceptable one.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.