-- Greg <[email protected]> wrote
(on Thursday, 25 August 2011, 11:55 AM -0500):
> > Thats not true. Autoloaders that are shipped with code should only
> > be responsible for loading the code they are responsible for (in the
> > least).
>
> Ok, I can agree with that. But thats were overheads can occur
> depending on the implementation of the rest of the spl registered
> handlers.
>
> As example, suppose the StandardAutoloader has a registered namespace.
> And when the StandardAutoload::autoload function is called and it
> determines that the class name is for that namespace but the class can
> not be located then by returning false, the next registered spl
> autoloader is called - but we just determined that the autoloader
> shipped for that namespace could not find the class - so whats the
> point in asking any of the other autoloaders?
Here's an example:
* You've created an application already, and have a classmap for its
class resources.
* You now need to develop a new feature for that application, which
requires new classes. Most, if not all, of these are in a namespace
that your classmap already knows.
This is exactly the situation the quickstart tries to accommodate. The
idea is this:
Zend\Loader\AutoloaderFactory::factory(array(
'Zend\Loader\ClassMapAutoloader' => array(__DIR__ .
'/../library/.classmap.php'),
'Zend\Loader\StandardAutoloader' => array(
'namespaces' => array('Application\View\Helper' => __DIR__ .
'/../application/views/helpers'),
'prefixes' => array(
'Default_View_Helper' => __DIR__ .
'/../application/modules/default/views/helpers',
'Zend_View_Helper' => __DIR__ .
'/../library/Zend/View/Helper',
),
),
));
The above accommodates both the case where the classmap cannot identify
the class (a simple "isset($map[$classname])" check), as well as
checking specific namespaces and prefixes.
One thing I've not mentioned: the StandardAutoloader allows you to
register multiple namespaces and/or vendor prefixes in a single
instance. Thus, if you're not using it as a fallback autoloader, it will
fail early -- if the class does not match a namespace/prefix in its
list, it returns false early. I think this is precisely the behavior
you're trying to describe; correct me if I'm wrong.
> For example, we want to find the Url view helper, heres our registered
> helper namespaces/prefixes.
>
> $prefixes = array(
> 'Default_View_Helper_',
> '\Application\View\Helper\',
> 'Zend_View_Helper_'
> );
>
>
> foreach($prefixes as $p) {
> $class = $p . 'Url';
>
> if (class_exists($p . 'Url')) {
> return $this->helper['Url'] = new $class();
> }
> }
>
> If there are two spl registered handlers, ClassMap (which knows all of
> the classes in the application) and the StandardAutoloader (and in ZF2
> lets say it is fallback enabled). Then if 'Default_View_Helper_Url'
> does not exist in the ClassMap Autoloader why should the fallback
> strategy of the StandardAutoloader even be executed - it would be a
> waste of time and i/o (which for ZF1 is not possible to prevent, if I
> can recall, unless there is only one registered spl autoloader).
If you don't want it to hit the fallback strategy... then don't register
the fallback!
The only reason we register it in the quickstart is for rapid
application development, when namespaces and vendor prefixes may be in
flux. If you don't want or need the fallback, simply don't register it
(it's off by default in the ZF2 StandardAutoloader).
The reason to use _multiple_ autoloaders is if you have either multiple
autoloading strategies you want to employ (e.g. classmap for most-often
used classes, PSR-0 for others), or have several different codebases
with different class->file system mappings that require multiple
strategies (heck, this is true in ZF1 -- library code vs application
code hierarchies differ!).
The recommendation for production is to _never_ use the fallback
autoloader strategy, and only use either classmaps, the
StandardAutoloader with explicit namespaces/dir or prefix/dir pairs, or
a combination of the two. These strategies ensure failing early.
--
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]
