> Yes, but even in that case the autoloader would not be triggered to > load \Foo_Bar because if you already have used \Foo\Bar previously, > that would have loaded \Foo_Bar as well.
Well, my original point is that what if both are not defined in the same file. It's not that far fetched of an idea. Let's say you're using Zend Framework 2. So one part of your application uses the \Zend\Registry class. Now, let's say you import a third party library that was built with a dependency on the ZF1 \Zend_Registry class. Without the require_once modification, it would fatal error since both are not in the same file (even though a later autoloader knows how to load Zend_Registry). Granted, it's a bit of a stretch, but it's not out of the realm of possibility. And considering it's trivial to avoid the error since all it takes is require_once, I think it's worth fixing... > Would it not be possible that the autoloader mechanism catch all exceptions > made by any autoloader which fails to load a class. Only if none of the > register autoloaders can load the requested class the autoloader mechanism > throws an AutoloadException with all the catched exceptions. This behaviour > should be controllable by the users environment. So if using an > autoloader(e.g. from a library) which throws an exception, but the user > doesn't use exceptions in his environment, he should be able to deactivate > the exceptions thrown by the autoloader mechanism. I think this behaviour > has the greatest advantages for both worlds. This one which needs exceptions > to shut down the application in an ordered way, and for these relying on > PHPs way to handle the autoloading error. Sure, it would be possible. But that would also be a BC break. It may be worth it (not sure), but still. An interesting idea... > Not sure debug adds much here - if the class is not found, you'll be notified > by the engine anyway, so what's the added value? I think what he was trying to do was provide an indicator of what the mapped file that it tried to load was. So not throwing the exception to show it failed, but throwing it to identify what the file path should have been. Not arguing if it's a significant need, just what was intended... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php