Hi!
ok, they have the same non fully qualified named.
That's why we should have unambiguous resolution mechanism. You propose
to add one ambiguity on top of another.
want to get generic \Exception instead of \My\Very\Specific\Exception
- it would probably break all your error handling.
this is about overloading and flexibility.
We never had class name overloading and I don't see why we should start
it. It's runkit domain, as I said. If you call certain class, you should
be able to know which class is that. I don't understand why when seeing
problem so big that it requires change of whole syntax in something like
foo::bar() - you fail to understand ambiguity potential in your proposal.
the point was that this gives the end user the choice of when, if at
all, to fallback to the global namespace. in this way the default could
indeed be 1) ns 2) autoload 3) fail. just that autoload can now handle
more cases in a manner the end users might deem sensible.
It's not autoload's task to change class names that it is loading. By
the time you use autoloader the class name should already be known -
otherwise you can't even decide if to use autoloader or not! And it
definitely will screw up everything if you use multiple autoloaders with
different ideas about how to rewrite class names. Please let's keep
autoloaders simple and not insert there hacks that do not belong there,
we have enough complexity there already.
i guess the other alternative (though actually i am not sure if its
possible), that people will likely try out is to extend the base class
inside the namespace on the fly. which i would consider much worse.
What are you trying to achieve here?
--
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
