Zeev Suraski wrote:
All,

One problem that became apparent after the introduction of __autoload(), is that different pieces of code, sometimes coming from different sources, may want to declare this function in a different way. Today, __autoload() is treated like any other function, so it's impossible to re-declare it.

Marcus tried to solve it by introducing an __autoload() wrapper in SPL. Personally I think it's probably not the right way to go, but that's beside the point right now.

What I'd like to suggest is a change in the behavior of __autoload(), so that multiple __autoload()'s could be defined. Essentially, declaring __autoload() would in fact add the function to the list of functions that are called in case a missing class is referenced. However, it will not actually place a function named __autoload() in the PHP function table. That way, it would be possible to declare multiple __autoloads(), and have all of them called when a missing class is spotted.

The two issues with this solution are:

1. It will be impossible to use the standard means to determine whether __autoload() is declared or not. I don't think that's a very important issue but it's there nonetheless.
2. We need to determine what makes sense as far as calling order if we have more than one __autoload(). My guess would be calling them in the order they were registered, and checking whether the class was defined after each one (if it was - stop).


That solution maintains downwards compatibility (almost, other than issue #1).

Thoughts?

Don't forget

3. If a library has an obscure bug in __autoload, the only error message the user will see is:

"undefined class XXXX"

If __autoload() is going to gain the ability to be defined for a library, then the error messages must be enhanced as well.

There is a possible solution:

1) document that coders of __autoload() should throw an autoload_exception if a class is not found

How difficult would it be to have a zend_autoload_throw() that would bubble up to the next __autoload() and save the exceptions in a hash for later display if necessary (exceptions need not be the actual implementation, obviously)? This way, each exception message thrown by an autoload could be displayed after the "undefined class XXXX", eliminating a large portion of the magic that makes debugging multiple __autoload() impossible right now.

Greg

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to