-- Greg <[email protected]> wrote (on Wednesday, 24 August 2011, 09:29 PM -0500): > Hi Matthew, > > > 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? > > > > 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. > > In my opinion, therein lays the problem. Each handler's register > method is registering with spl_autoload_register, which the developer > cannot halt if a class for a particular namespace is not found, since > the handler's autoload method typically returns false, causing the > spl_autoloader to move onto the next registered handler (there is no > way of preventing _spl_ from continuing?).
Again, why is this a problem, exactly? What if you have another autoloader registered later that _can_ handle it? > For example, say the StandardAutoloader is registered and has had > namespace 'Ant' registered with it. And another handler is also > registered with the spl_autoload_register (similar to what's in the > quickstart). Then if class_exists is called for 'Ant\test', the > standard autoloader will return false (since it doesn't exist), > causing the spl_autoloader to move onto the next registered handler > when it shouldn't, especially when chances are none of the other > handlers know anything about that namespace. While there may be some additional execution cycles, in most cases, the logic behind autoloaders should be written such that the overhead is minimal. This is, in fact, why we're advocating class maps and explicit namespace/path pairs for ZF2 -- so that autoloaders can fail early and quickly if they are incapable of locating a class file. > So instead, I'm thinking, there should be only one (stack like) > handler registered via spl_autoload_register, But spl_autoload _IS_ a stack!!!! > and any other handlers would register with that single stack like > handler instead of directly registering with the spl_autoloader. This > would give the handler a way to indicate that the autoloading > mechanism should halt its process and not waste any more cycles or > file/io lookups. So, would the idea of having AutoloaderFactory act as a priority stack, registering a single entity with spl_autoload, but containing many autoloader strategies internally, work for you? As mentioned before, the autoloaders written for ZF2 pretty much work as you indicate -- they fail early if they cannot locate the class file. This would also still allow developers to register additional autoloaders when they want to provide alternate strategies to fall back on. > For example, with the ZF1 code I wanted to try an optimize the > autoloading mechanism after introducing the Class Map back port you > provided. Try making that handler the only autoloader for ZF1, its not > clean. And with a class map to hand there is no need for the View > Helper to file hunt, try changing file_exists to class_exists and > notice the unnecessary subsequent autoloader calls if more than one > handler is registered with spl. This is the nature of autoloading -- it tries every strategy it can until no more are possible before it fails. It's very useful to have multiple strategies available, and to be able to intercept when one or more fail. -- 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]
