Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15758
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <425002D8.50004@php.net>
Date: Sun, 03 Apr 2005 10:51:04 -0400
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Zeev Suraski <zeev@zend.com>
Cc: internals@lists.php.net
References: <5.1.0.14.2.20050403125628.03f83de0@localhost>
In-Reply-To: <5.1.0.14.2.20050403125628.03f83de0@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: __autoload() enhancement
From: cellog@php.net (Greg Beaver)

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