> Von: David Zülke [mailto:[EMAIL PROTECTED]
> 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. You got a point. > 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 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. Exactly what Chuck and Greg tried to point out, providing examples for what you describe. http://www.mail-archive.com/internals@lists.php.net/msg31217.html In my opinion one of the biggest weak points. In order to make things work consistently and reliable (behaviour does not change because of the order in which files are included or because new core classes are added), you need to 1) make sure all the stuff you use is already known (that is, refrain from using __autoload and revert to require() at the top of your files) or 2) explicitly use/import all your classes, even the ones from your namespace inside your namespace. That is because __autoload comes after internal classes (which comes after already known classes from the current NS) for unqualified names. Approach 1) makes the names "already known", 2) turns the unqualified names into qualified ones by means of aliasing. :( -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
