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
>

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



Reply via email to