- I agree that explicit imports show what files your code relies on, that doesn’t necessarily translate to classes. With a good autoloading strategy (ie, one class per file, and having the class name correspond to the location and name of the class) it’s very easy to figure out what classes you’re using.
- Large codebases get confusing real fast if there is not a defined mapping of how to name files and classes. If you’ve got two different “Account” classes and don’t have them either namespaced or class prefixed, you’re probably going to have problems anyway.
- The stat call is something you’ve got to do explicitly in your autoloader if that’s the behavior you want. It’s not required. Zend Framework’s autoloader up until 1.8 didn’t use a stat call. It just did a require on the code which meant 2 things… First it was faster since it didn’t have a stat call, but second, if you were stacking autoloaders, the Zend loader would need to be done last since require will bomb if the file doesn’t exist. The current version lets you configure this behavior.

Say perhaps you’re writing code using a strategy pattern. The code to provide that strategy is determined at run-time. If you go with the autoload way of doing things, only the classes and interfaces you need will be loaded. If you go with require[_once], you’ll be including all the classes all the time, even if they aren’t needed. That adds parsing and memory overhead. If you go with include[_once] and only load the classes right before they are needed, you’ve no longer got the benefit of having all the classes you’re using in one place (typically the top of the file), and if it’s critical those files be loaded, include[_once] isn’t going to bail if there was a problem loading.

- Lastly, who says lazy cannot be right? I think the benefits of using autoloader(s) greatly outweigh the downsides. The benefits are there both for the developer (not having to jump up to the top to include a new class for another file), the performance (only including files that are requested, even if the code may have references to other classes on non-executed lines). Additionally, as Brandon mentioned, new classes don’t need to be registered somewhere. If you have any code that dynamically generates classes that may or may not actually exist, this can be a huge benefit.

- It makes your code WAY less clear. Explicit imports document the classes your code relies on.
- Large code bases become real confusing real fast.
- It’s slow. stat() Not there? stat() Not in this other place? stat() Not over here? stat() Oh, here it is?
- It’s lazy, not “right”.

Example:
spl_autoload_register(‘library_autoloader’);
spl_autoload_register(‘app_autoloader’);
spl_autoload_register(’3rdparty_autoloader’);

$calc = new App_Calc; // the library_autoloader() is tried first and fails. the app_autoloader() is tried second and succeeds.

I see now, really handy to register classes that have multiple dependencies, nice :-)

@SchizoDuckie spl_autoload_register lets you register a callback which can then be used multiple times without having to individually register the classes. This means that when you add new classes, new registration isn’t required.