-- Greg <[email protected]> wrote (on Wednesday, 24 August 2011, 07:34 PM -0500): > > > if (false === class_exists('ClassA')) { //dynamically check to see if > > > a local overriding class exists via the autoloader > > > $class = new DefaultClass(); > > > } else { > > > $class = new ClassA(); > > > } > > > > What is an "overriding class"? > > In the above 'overriding' is the 'preferred' class to use, else use a > default one (which doesn't have to be of the same namespace). > > > By doing that, you can be sure that the stack of autoloaders is > > exactly as you expect it to be. You can also use the PHP 5.3 only > > feature of spl_autoload_register "prepend flag" to ensure things are > > in the order you expect them to be in: > > Even with the prepend flag it doesn't alleviate the problem, because > if 'Class A' is not found in the first registered autoloader, all of > the other (if any) autoloaders are then called - which in the above > example would be unnecessary. > > To me the problem is somewhat similar to finding a ZF1 View Helper, it > iterates through until it finds one. > > My point, or preference is, is that we should try and encourage only > registering one autoloader handler for the application.
Why, exactly? What problem does this solve? Multiple autoloaders helps solve the problem of allowing different autoloading strategies -- which may be due to performance considerations, differences in filesystem hierarchies, etc. I'm not sure why we would desire a single autoloader, so if you could provide some use cases, that would help us better understand your arguments. > I've also wonder it should be similar to ZF1's plugin priority stack, This is somewhat possible with spl_autoload(), as Ralph already indicated; it's also trivially easy to create an optimistic autoloading solution using SplPriorityQueue to loop through strategies. > which may also then provide the developer more control of the > execution stack (if needed). Currently in ZF2, we have an AutoloaderFactory, and you register autoloaders in the order in which you want them searched. This could be altered to use a priority queue internally. It's not exactly "a single autoloader", but then again, it sounds a bit like you're mainly wanting to be able to control the order of execution. This approach could solve that. > I realize that in ZF2 this may not be an issue if say > only the Class Map autoloader is the only registered handler. I don't anticipate this at all, actually. I anticipate a combination of class map autoloading, PSR-0 autoloading with explicity namespace/path pairs, and PSR-0 fallback include_path autoloading. This hybrid approach makes for a good story from development (when namespaces and paths are often in flux) to production (when you need to milk performance). > For example, if the handler could prevent the autloader stack from > automatically continuing onto calling the subsequent registered > handlers because the one for that namespace knows it could not find > and that none of the handlers will either. This is in fact how the StandardAutoloader (PSR-0 implementation) in ZF2 works -- you register explicit namespace/path pairs; if the requested class does not match the given namespace, it moves on to the next handler. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- List: [email protected] Info: http://framework.zend.com/archives Unsubscribe: [email protected]
