On Wed, Mar 12, 2008 at 2:53 PM, Andrés Robinet <agrobinet@xxxxxxxxxxxxx> wrote: > I think __autoload would make much more sense if it worked like an event > registration feature. Such as: > > function myAutoloadCallback($className) { > if ($className == 'ShakeItBaby') { > require_once 'ShakeItBaby.class.php'; > return true; > } > return false; > } > ..... > > __autoloadRegisterCallback('myAutoloadCallback'); > ..... > > $shaker = new ShakeItBaby(); > > This way, multiple frameworks and project requirements for autoload > wouldn't clash. If one of the autoload callbacks returns "true" that would > be it. Otherwise the next autoload callback would be called, and so on. > > The problem with the current implementation is that if you get some piece > of code that uses __autoload and you are using __autoload too, you'll have > to either patch that piece of code (if the "piece of code" is a framework, > things will get much more complicated when updating to the next version) or > patch your own code, or just make a promise not to use __autoload (my > current choice... just in case) or not to use "pieces of code that use > __autoload". Bottom line, I hate it. as eric pointed out earlier, thats what spl_autoload_register is for; http://us.php.net/manual/en/function.spl-autoload-register.php -nathan