Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
If it worked this way, you couldn't easily use global classes and
old applications would be much harder to convert to namespaces. We
think that using global Exception is much more frequent than
defining your own Exception - and in the latter case you have the
choice to name it something that is not the same as existing class,
while in the latter case you do not.
If you look at the various PHP 5 class libraries or frameworks, pretty
much all of them define an Exception for every package -
Zend_Db_Exception, Zend_Http_Exception, etc.
Calling exception classes something other than Exception is kind of
like giving up on the namespace - if I have to name my classes,
*inside* their namespace, specially in order to avoid global class
names, then that seems very unintuitive.
The other alternative would be to say that if you want to use a
global class inside a namespace you MUST prefix it with ::. I think
this is
We consider it not the best choice. Using of global classes is
ubiquitous in current applications, always requiring :: would make
it very hard to convert them to namespaced code. We think it would
require much more work than just having "require_once" in places
when you override the internal classes.
I agree. I think Greg and I have a better solution: if you want to use
a global class, import it. You can use :: if you want, but again I
will say that we are talking about code _inside_ of a namespace. It
would not add much conversion burden to say that if you want to use
global classes in a file you are adding a namespace to, then just add
imports for those classes. If PHP provided a PHP:: namespace with all
global classes in it (as aliases), then you could just do import PHP
and be done with it. People who wanted their namespace to be used
instead would just not do that.
-chuck
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
