Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15751
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: Zeev Suraski <zeev@zend.com>
Cc: internals@lists.php.net
In-Reply-To: <5.1.0.14.2.20050403125628.03f83de0@localhost>
References: <5.1.0.14.2.20050403125628.03f83de0@localhost>
Content-Type: text/plain
Date: Sun, 03 Apr 2005 20:58:36 +0800
Message-ID: <1112533116.27505.16.camel@alanportable2.hklc.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] __autoload() enhancement
From: alan@akbkhome.com (Alan Knowles)

I dont know if you read the blog comments here:
http://www.akbkhome.com/blog.php/View/79/require_once+is+part+of+your
+documentation..html
and here
http://www.akbkhome.com/blog.php/View/77/is+__autoload+evil%3F.html

and slightly related
http://www.akbkhome.com/blog.php/View/76/require_once%2C+one
+optimization+too+many%3F.html

It's pretty clear that people want to use autoload to save them having
to deal with include paths.. (and perhaps save a few stat calls) - the
more straightforward solution would be to add a include/require callback
handler - so that rather than a class instantation action, magically
doing file operations, you had a simpler and more obvious way to manage
inclusions.

But I guess Until I bother hacking something up for it, it'll remain
little more than another heckle from the audience. ;)

Regards
Alan

On Sun, 2005-04-03 at 13:05 +0300, 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?
> 
> Zeev
>