Page 1 of 1

autoload VS spl_register_autoload

Posted: Sun Jul 26, 2009 2:25 pm
by alex.barylski
It seems each SPL autoload is executed obviously, unfortunately each one uses a different base directory and so when the first one is invoked it doesn't find the file and triggers an error, whereas the second is the appropriate autoload and does find the file but its too late as an error has already been raised.

I will likely use a file_exists and just exit silently if not found but I dislike this approach because I would actually like to know whether a class failed to include...

Ideally I only want the error to trigger after the last autoload has failed to find the file but being an autoload function the last thing I want in there is a GLOBAL or registry to keep track of an error stack.

Any ideas? Should I just log the error or take comfort in knowing that an object that doesn't have it's class included will trigger an error when instantiated?

Re: autoload VS spl_register_autoload

Posted: Mon Jul 27, 2009 6:02 am
by Jenk
Observer attached to all autoloaders, then go from there?

Re: autoload VS spl_register_autoload

Posted: Mon Jul 27, 2009 10:01 am
by alex.barylski
Hmmm that would be one way, only what do you do about libraries that already have their own implementation of an autoload function registered with apl_register_autoload?

Can you unregister autoloaders? (Checking php.net). Seems you can unregister/replace existing autoload callbacks...so I suppose I could just unregister each spl_autoload_* and define my own -- not quite implementing an observer but keeps everything cetralized and free of object dependencies, which I would probably have to bring in via a static call to a registry...

Actually now what I'm thinking...is maybe unregister the autoloaders for each library used in my application...implement my own and using class prefixes, determine which of the autoloaders to re-register, ugggh...that won't work nevermind. :P

Basically I'm looking for a way to use the libraries individual class inclusion code inside the master autoload implementation.

Am I missing anything that you can think of?

Implementing a single master autoloader as a strategy instead of attaching observers (somehow??) to each existing autoloader???

Cheers,
Alex

Re: autoload VS spl_register_autoload

Posted: Mon Jul 27, 2009 5:59 pm
by Jenk
Could always decorate the libraries autoloaders, then you'll be able to add a seam for your logging/observing :)

So to that end, you'd need to unregister, decorate/wrap, re-register. Though that might be overkill.

Perhaps intercept the error handling? set_exception_handler()/set_error_handler() ?