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