Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15764
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20050403174225.05c1a9b0@localhost>
Date: Sun, 03 Apr 2005 17:46:29 +0300
To: Alan Knowles <alan@akbkhome.com>
Cc: internals@lists.php.net
In-Reply-To: <1112533116.27505.16.camel@alanportable2.hklc.com>
References: <5.1.0.14.2.20050403125628.03f83de0@localhost>
	<5.1.0.14.2.20050403125628.03f83de0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] __autoload() enhancement
From: zeev@zend.com (Zeev Suraski)

Alan,

Your blog entry is actually what made me look into that topic.  I'm not 
sure whether I agree with you regarding the general necessity of 
__autoload().  __autoload() is not only about saving the headache of 
explicit require()'s, it's also about 'JITing' this task, so that no 
classes are loaded unless you actually use them.

The main things I took from there are that __autoload() is broken since 
it's limited to just one declaration, and that somehow an alternative was 
introduced into SPL, which is slightly scary.

Zeev

At 15:58 03/04/2005, Alan Knowles wrote:
>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
> >