Question

When building a library I always provide an Autoloader class that handles autoloading for the library. The autoloader is registered like this:

require_once 'path/to/PHP-Parser/lib/PHPParser/Autoloader.php';
PHPParser_Autoloader::register();

I’m not sure though how to handle it if my library depends on another library. Imagine that PHPParser depends on a PHPLexer. Now when using the library one would need to write:

require_once 'path/to/PHP-Lexer/lib/PHPLexer/Autoloader.php';
PHPLexer_Autoloader::register();

require_once 'path/to/PHP-Parser/lib/PHPParser/Autoloader.php';
PHPParser_Autoloader::register();

If there are more than just one dependency or the dependencies have dependencies themselves, this can get messy quickly.

So how should one handle dependency autoloading?

One idea I had was that the library should handle autoloading for it’s dependencies too, but that just doesn’t feel right. Another idea would be to not provide an autoloader at all and assume that people use the UniversalClassLoader. That though doesn’t seem right either.

Answer 1

Well, there are a few ways to solve this problem, each with their own pros and cons:

1. Use a common PSR-0 autoloader for all the libraries, and just register the location of the other project when initializing it.

   • Advantages:
     1. Very simple to implement
     2. Uses same code, so only one autoloader to use
     3. You can register all the paths in your application bootstrap file, so all library autoloading is defined in one place
   • Disadvantages
     1. Requires all libraries to implement a PSR-0 compatible file structure
     2. Leaks the abstraction level a bit since the application bootstrap needs to bootstrap everything inside the application including each individual library.
     3. Tightly couples the library’s file structure to your autoloader (if a library implements a new file that conflicts, it’ll break your autoloader even though theirs works file)

2. Define a custom autoloader for each library.

   • Advantages
     1. Very simple to implement.
     2. Keeps library autoloading semantics in the library.
     3. Better maintainable code due to separation of responsibility
   • Disadvantages
     1. Lots of hard-coded classes in your bootstrap file (not a big deal though)
     2. Performance since an autoloaded class must go through multiple autoloaders
     3. Leaks the abstraction level since a library may need more effort to bootstrap than just an autoload

3. Implement a bootstrap.php for each library (preferably provided by the library)

   • Advantages
     1. Pretty simple to implement.
     2. Keeps library autoloading semantics in the library
     3. Better code due to separation of concerns
     4. Ability to define non-trivial library bootstrap code without clouding other parts of the application
   • Disadvantages
     1. Still require a require_once '/path/to/lib/dir/bootstrap.php'; to initialize
     2. Performance (for the same reason as the 2nd solution)
     3. Most 3pd libraries do not implement a bootstrap file, so you may have to maintain one.

Personally, I use the third option. An example is the bootstrap.php file in my CryptLib library. To initialize it, just call bootstrap. You could also use any PSR-0 autoloader and just not call bootstrap.php, and it will work just fine. But with the bootstrap option, if I added functionality which needed to register itself at startup, I could just add it to the bootstrap.php file and it would automatically be executed (rather than telling users that they will need to do “x, y, z” on startup)…

With respect to the universal class loader option that you mentioned (calling spl_autoload_register() with no arguments), I personally don’t like that option. First of all, it lowercases the classname (which is in violation of PSR-0, and I don’t like it. I have gotten used to case sensitive class -> path mapping, and actually prefer it that way now). Secondly, it always uses relative paths, so it will defeat most opcode caches. There are other issues, but those are the big ones…