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);"?
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.
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.
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.
nico
