X Autoload

This module implements PSR-0, PEAR, "PSR-0-NG" and "PEAR-NG" (7.x-2.x branch) autoloading for Drupal 6 and Drupal 7.

X Autoload does establish a standard for how to name your module-provided classes and where to put those class files ("PEAR-NG" in $module_dir/lib/), but it can be configured to support other patterns as well. Especially, it does support a Drupal 8 style directory structure (PSR-0 in $module_dir/lib/), if you run PHP 5.3+.

News:

• March 10, 2012: Blog post with implementation details on dqxtech.net. Attention, this is a long read.
• March 09, 2012: Published 7.x-2.x branch with full rewrite, based loosely on SymfonyUniversalClassLoader, bringing full unit-testability, support for PHP 5.3 namespaces, PSR-0 and "PSR-0-NG", pretty much anything that was ever proposed for Drupal 8 autoloading. Still needs more unit tests!

Without xautoload (D6, D7)

Without this module, autoloading in D7 core and in D6 autoload module does work like this:

• Modules can define a files[] array in their info files. All these files are scanned for class definitions, whenever an administrator flushes the files registry.
• The autoload callback then looks into the scanned registry information.

This results in an undesirable situation:

• Classes can be placed in arbitrary files, in arbitrary locations, mixed with other stuff.
• Class names are arbitrary, name clashes are easily possible.
• info files are bloated with files[] information. Just look at the views module.
• The module developer needs to keep the files[] information up to date, whenever a php file with classes in it is created, renamed or moved around.
• The scanning can take some resources (although it is usually acceptable).

With xautoload (D6, D7)

Classes using xautoload are named as

This autoload mechanism does work in parallel with the existing one.

Benefits

• Enforced conventions of how to name classes and files, and where to put them.
• Easier to port your module to D8.
• Easier to backport changes from the D8 version of your module to the D7 or D6 versions.
• No more bloating your *.info files with files[] directives.

Alternative files[] wildcard syntax

In addition, xautoload enables a wildcard syntax for the files[] directive. This allows to clean up your info files, but keep class files where they are, so you can do the real xautoload transition another day.

This has little performance implications, because the scan only happens when the class files registry is rebuilt.

For example, in views.info, the files[] stuff could be replaced with

The /*/ wildcard can be any string between two slashes.
The /**/ wildcard can be either / or /*/ or /*/*/ etc.
A /** ending a string can be just anything starting with a slash.
A /*.inc ending a string is a filename with a ".inc" extension.

Drupal 6

In D6, if you also use the autoload module, files within the /lib/ folder will be scanned recursively, and the result saved in the registry, for any module that has a "autoload = 1" setting in its info file. We hope that this does result in a performance benefit.
(attention: this mechanism is not tested yet)

Modules that (will) use xautoload

Some of these modules have a compatibility fallback, to avoid having xautoload as an explicit requirement. Still, they should work better with xautoload enabled.

(the xautoload supported version might still not be released yet, wait a bit before you complain..)

• Crumbs
• DQX AdminMenu
• Imagene gradient generator
• PageAPI
• List to be extended, let me know for other modules.

Downloads