Nicollet.Net

Back in the old days of PHP 4, every script started with a shopping list of include statements for other files.

PHP 5 brought along the __autoload function, and people were overjoyed. Since most programmers already had some kind of mental rule that said « class Foo is defined in Foo.php, » PHP let those programmers write down the rule and then followed it when looking for classes that had not been defined yet. A simple example would be:

function __autoload($classname)
{
  @include "$classname.php";
}

The classic PHP 5 architecture moved from « write a shopping list at the top of every script » to « include the file that defines __autoload » and even « redirect all requests to a single index.php file that defines __autoload and dispatches the requests. »

And the tutorialosphere went wild. People everywhere discovered the power of autoloading and expounded on the usage of __autoload as the next step in PHP evolution. A Bing search for __autoload (or google) will bring up many such one-page tutorials that discuss the benefits of that function for the sake of wide adoption.

But meanwhile, __autoload’s little sister spl_autoload_register remained unknown, despite a major difference:

If there must be multiple autoload functions, spl_autoload_register() allows for this. It effectively creates a queue of autoload functions, and runs through each of them in the order they are defined. By contrast, __autoload() may only be defined once.

With __autoload, your code breaks if you ever need to interact with code that uses its own autoloading approach. While you can usually turn __autoload into spl_autoload_register in a few key presses, you might not have sufficient control over the code to make that change.

Case in point: Joomla! is a well-known content management system (often said to be the third of the Drupal-Wordpress-Joomla! triumvirate of PHP CMS solutions). Since version 1.5, it uses __autoload. It looks like this:

function __autoload($class)
{
  if(JLoader::load($class)) {
    return true;
  }
  return false;
}

If you need to make Joomla! and the Zend Framework talk to each other, you need to include Zend Framework files by hand because you can’t add Zend_Loader on top of __autoload.  While it would be possible to change Joomla! to use spl_autoload_register instead of __autoload, this change will probably be overwritten by the next update you download.

In short, if you write code that will be used by people who do not own it (in the sense that they can change it without annoying side-effects), you need to use spl_autoload_register() instead of __autoload().

In the case of Joomla!, a simple patch would be to remove the __autoload() function definition and replace it with:

spl_autoload_register(array('JLoader','load'));

(In fact, there has already been one such suggestion made there).

Related posts

• PHP Autoloading : yes, I made that mistake once, too
• Pervasive code : an unusual class-to-file mapping in JITBrain
• Singletons : having a single autoloader carries the typical issues of one-instance-only entities