Again, why is this a problem, exactly? What if you have another
autoloader registered later that _can_ handle it?
If the first dedicated autoloader for that namespace couldn't handle
it, chances are no other handler will (or should not).
Thats not true. Autoloaders that are shipped with code should only be
responsible for loading the code they are responsible for (in the least).
Try as we might, the one class per file / 1:1 mapping of
namespace/classname to filesystem name is still just a suggested best
practice, and we cannot cover every mapping a developer might come up
with. That's not to say their code (that you might want to consumer in
your ZF application) is not useful, it just means we cannot autoload
things that are not of a standard mapping. I've still seen:
* devs put class in the file name SomeClass.class.php
* devs put multiple classes in a file
* devs don't use logical prefixes or namespaces
Simply put, the best practice here is to let the 3rd party autoloader
handle the 3rd party code. Each autoloader should short-circut/return
early if it is being asked to handle a class it is not responsible for.
The CONSUMER is ultimately responsible for properly organizing their
spl_autoload_ stack in some bootstrapping process and ensuring the code
they are consuming actually does play nice with other code.
But spl_autoload _IS_ a stack!!!!
I realize that, the point was that the application code cannot break
out of the execution loop if desired.
By the time you are executing your application, you should not be
concerned with either the who, what, why, or how a class is located an
utilized. Simply put, that's too much information for the application
layer.
This is the whole point of delegation. This is probably a good read for you:
http://en.wikipedia.org/wiki/Java_Classloader
Things are not so completely different with regards to how JVM and PHP
have decided to solve the problem of dynamic class resolution.
Ultimately, if you're trying to influence which class of the SAME NAME
your application is attempting to use, you probably have some bigger
architectural issues to be dealing with.
As much as I appreciate that the zf2-quickstart example, is exactly
that, but it does somewhat exemplify the point I'm trying to make
since in that example, the StandardAutoloader would execute given the
namespaces registered even though there are class maps also - I
realize it is just example code.
My original post was more to draw awareness to potential overhead that
could be incurred if the we're not cognitive of the implications
(depending on how and what is being used).
What exactly is the overhead? In all of my research, multiple small
concise autoloaders are always faster than one monolithic autoloader.
The idea behind the Zend\Loader component is to give developers options.
The options allow developers the ability to write code that will play
nice with older 3rd party code (think prefixed code) as well as newer
3rd party code (namespaced). Also also give developers to option to
compile classmaps in situations where performance is a top priority.
-ralph
--
List: [email protected]
Info: http://framework.zend.com/archives
Unsubscribe: [email protected]
