Calling exception classes something other than Exception is kind of like giving up on the namespace - if I have to name my classes, *inside*
Not entirely correct - namespaces needed to reconcile _multiple_ libraries, while in case of Exception you need to stay away only from _one_ set of classes - namely, internal ones. While indeed even that could be inconvenient, the problem is that it is not possible to avoid ambiguity in all cases successfully, so we had to choose how we solve ambiguous cases. We decided to solve it in a way that gives most old code most chance to work, while knowing that some people would find some code less convenient with any code. Out solution allows to explicitly specify your intent in one of these ways:
1. Defining the class 2. Importing the name
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
I think it would. It is much easier to keep track on your own classes than on system classes create by somebody else. And with exception of Exception (no pun intended :) I think there would be not many classes that would have names coinciding with internal class names.
(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.
If you are OK with writing imports, then it shouldn't matter too much which imports you write. Right now you need to write your imports - or explicitly specify the class, or load the class. I would like to find better solution, but completely masking system classes with overloads and allowing only :: to work doesn't seem the best way to me currently. Also it would cause autoload call on each use of system classes even if you never had overridden them at all, which can have significant impact on the performance - exhaustive autoload search can be very expensive.
-- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
