This post originated from an RSS feed registered with PHP Buzz
by Alan Knowles.
Original Post: is __autoload evil?
Feed Title: Smoking toooo much PHP
Feed URL: http://www.akbkhome.com/blog.php/RSS.xml
Feed Description: More than just a blog :)
Someone asked on a few of my other posts why I refer to __autoload as evil, (well apart from making sensationlist statements to keep the blog interesting).
lets start with what it's supposed to get rid of.
require_once 'SomeClass.php';
$x = new SomeClass;
The code above is reasonably predictable, require_once will look in the include path, and find the first match of SomeClass.php, the second line will create an instance of the class that looks like it's probably in SomeClass.php The only magic here is
Which of the include paths SomeClass.php might be in..
Now enter __autoload. I first saw __autoload on the Zend developers list, it's one of the methods that you looked at and thought, 'is this really a good idea?'. But ignored it, since like all features of any language - 'You dont have to use it'.. or so I thought..
Autoload basically hooks into a few places so when you would normally get a 'this class does not exist' message, autoload is called to let you try and load it, and hence avoid this message.
It also hooks into class_exists(), and gets called to let you try and load the class then, hence the purpose of
class_exists('PEAR') or require_once 'PEAR.php';
On the face of it, the above looks like it is just saving you a file call that require_once isn't really supposed to be doing.. but no.. class_exists is really secret code for 'you can have a go loading the PEAR class from wherever you like'
The justifications I've seen for this are two fold
It's better from a performance point of view.
It's more flexible.
The first argument, is extremely questionable, the microseconds that you may be saving, compared to parsing all the code that you have in all the classes is probably so tiny as to not be a particular issue. And almost all of it could be removed by using APC or similar if you really where that desperate for performance tweaks.
The Flexibility issue is also questionable, What can you do with autoload that cant be done with include path? or more to the point, what are you doing messing around with include path and autoload locations in the first place.., trying to dig a bigger bug hole for you or someone else to discover later..?
And finally into the fray spl_autoload Meanwhile as all this was going on, Marcus added an autoloading toolkit to spl, the new 'Standard PHP Library', or perhaps the 'I need more classes library'. What has been added is the missing ability of autoload to be impliemented multiple times.
You can only define one __autoload method per instance of PHP, however spl_autoload allows you to register as many handers as you like, hence multiplying an already magic tool at infinatum. Now you may as well prey that what you typed is actually going to be run as you requested..
Is include_path so complex, troublesome or unflexible that it needs to be replaced with something so much more complex and flexible?
or does somebody want to do something so horrific with __autoload that they are dieing for this tool?
Previous Topic
