On Wed, Mar 12, 2008 at 2:53 PM, Andrés Robinet <[EMAIL PROTECTED]>
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
