-- Nico Edtinger <[email protected]> wrote (on Sunday, 10 May 2009, 02:09 AM +0200): > Matthew Weier O'Phinney wrote: > > Zend_Loader's autoload solution has been basically broken from the > > outset, and there's no way to fix it cleanly within that class. > > Zend_Loader_Autoloader provides a much better solution that covers all > > the use cases thrown at it so far: ability to toggle suppression of > > errors, ability to register namespaces and do opportunistic mapping of > > namespaces to autoloaders, ability to add instance methods as > > callbacks > > to an autoloader -- and then remove and/or re-add them if desired > > (something spl_autoload does not support cleanly), etc. > > > > Note that we're marking Zend_Loader::autoload as _deprecated_ -- it's > > not being removed, but we're giving fair warning that you may want to > > update your code. This is a practice we've been using for some time to > > mark deprecated code. > > What's wrong with replacing the code in Zend_Loader::registerAutoload() > with > "Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true);"?
Okay, that's the first constructive feedback I've received on this matter, and it's a really nice solution. I still want to keep Zend_Loader::autoload() and Zend_Loader::registerAutolaod() as deprecated, as developers should move towards using Zend_Loader_Autoloader directly. But this is a nice solution that ensures they are (a) getting the right solution, and (b) only generating a single notice. > It's quite usual to have one just one directory in your include_path and > classes prefixed. A common practice is something that should be the > default instead of an option that needs to be turned on. Also > registerAutoload says what it does, getInstance does not. The issue is that Zend_Loader_Autoloader is (a) a singleton, and (b) has no use case without being registered with spl_autoload -- so doing the registration when first retrieving an instance is the best course. As for whether or not the autoloader should be a fallback autoloader by default -- I disagree. This has been the root of many, many issue reports, and is why we decided to go with a namespaced autoloader. > I do unterstand that with a modular MVC setup with different namespaces > in different paths a simple autoloader doesn't work. But not everyone is > using the MVC parts (use at will). And since 1.8 you don't have to worry > about the loader at all, as Zend_Application is handling everything for > you. Namespaced autoloading is not directly related to modular MVC setups -- it's about allowing multiple autoloaders to play cleanly with one another. > As long as Zend_Loader itself isn't deprecated I'm all for keeping > Zend_Loader::registerAutoload() to enable the best practice, using > Zend_Loader_Autoloader, instead of deprecating it. Zend_Loader won't be deprecated. However, as noted above, registerAutoload() and autoload() *will* be deprecated. There's no reason to keep registerAutoload() around simply to proxy to Zend_Loader_Autoloader. That said, I *really* like your idea to proxy to it in the short term during the deprecation phase, and will be acting on that advice. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/
