The problem I see with that is that if I have an application that uses a 3rd-party library which does not use namespaces, I need to use ::LibClass everywhere. Until they switch to namespaces - then I need to touch hundreds and thousands lines of code. If LibClass were looked up in the global namespace, too, I could simply add the appropriate import statements at the top of each file.
But also it means that namespaced library would be influenced by any use code around, which was exactly the thing we tried to avoid.
Anyways, the process you described seems flawed in another fashion: It looks up a class in the namespace first, then an internal php class, then it tries an autoload. That does not make sense. Lets say I run some
Actually, it does :)
code as you described, and there is a class C(), but it's not been autoloaded yet. The internal class C is used. Then, later, the autoloading of A::B::C() is somehow forced. Now, if the same code runs again, a different class is used. That sounds like nonsense.
Not, it's not nonsense - try to find other way that allows overriding internal class names and doesn't force exhaustive autoload search on each access to internal class - and you'll understand why it makes sense.
-- 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
