Drupal and __autoload
Crell published some interesting benchmarks in 'Benchmarking magic'. He mentions the overhead of loading and parsing in PHP being a big bottle neck in the comments. My current project uses a few classes that kind of clutter the .module and aren't always used. Having PHP magic functions on the mind I immediately started thinking about __autoload and Drupal.
Paths are an issue for includes with Drupal modules... You never quite know where your module will be in an installation. You can also only have a single _autoload() function. So to keep life simple for myself I decided to stash args for drupal_get_path in my class names.
<?php
function __autoload($classname) {
$parts = explode('_', $classname);
$type = array_pop($parts);
$name = array_pop($parts);
$file = array_pop($parts);
$path = drupal_get_path($type, $name) .'/class.'. $file .'.php';
include_once($path);
}
class module_mediaAPI_media {}
class module_transformer_transform {}
?>This makes drupal try to load:
sites/all/modules/mediaAPI/class.media.php
sites/all/modules/transformer/class.transform.php
It would be nice to standardize an __autoload as Drupal starts taking advantage of more OO capabilities. Maybe Crell would be nice enough to plan out some __autoload benchmarks in the future... *hint* *hint*
If you wish to show appreciation for my Drupal Development...
Comments
Way ahead of you. :-)
Hi, Darrel. Actually, using __autoload() is considered bad form these days. The better alternative is spl_autoload_register(), which lets you register multiple autoload functions that can stack.
However, I am working on a centralized function/class registry for Drupal 7 that will allow Drupal to introspect itself and figure out where any function or class lives, and then autoload both on demand. (It only works for indirect function calls, but that's most of the useful functions in Drupal anyway.) Think of it as the Drupal 6 page split code meets chx's old split-mode code, but infinitely more flexible.
I have a proof-of-concept module in my sandbox here if you want to have a look. More details to come when HEAD opens up again.
By the way, requiring registration to post comments, and then enabling neither logintobaggan nor drupal.module nor OpenID is a huge PITA. :-(
good to know you're on it...
Awesome I'll have to look in your sandbox. :) Oh I enabled openid just for you. Hopefully soon I can make this site my own identity provider. I just did a rough update of the openid_server module to D5. It still needs some love. I hope Walkah or Rowan have time to get around to making it actually work sometime soon. I want to start working on DISO enabling my blog. :)
.darrel.
__autoload() is the wrong
__autoload() is the wrong function to use here. SPL, included in any worthwhile version of PHP 5 (meaning 5.1+), offers a stackable mechanism instead: http://us.php.net/manual/en/function.spl-autoload-register.php
Having a standardized autoloading mechanism in core makes a lot of sense when dealing with PHP 5 and objects, but I don't know how much that's going to happen in D6. In D7 we'll definitely want some central mechanism, but we don't know yet how heavily D7 will be using objects in the first place. (chx and I are supposed to have an argument about that shortly. ) It may be too late for D6 to make this sort of API change, though.