Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15742
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20050403135128.03e32320@localhost>
Date: Sun, 03 Apr 2005 13:53:38 +0300
To: Andrey Hristov <php@hristov.com>
Cc: internals@lists.php.net
In-Reply-To: <424FD1C8.7050206@hristov.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="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] __autoload() enhancement
From: zeev@zend.com (Zeev Suraski)

At 14:21 03/04/2005, Andrey Hristov wrote:
>Zeev Suraski wrote:
>>All,
>>One problem that became apparent after the introduction of __autoload(),=
=20
>>is that different pieces of code, sometimes coming from different=20
>>sources, may want to declare this function in a different way.  Today,=20
>>__autoload() is treated like any other function, so it's impossible to=20
>>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=20
>>beside the point right now.
>>What I'd like to suggest is a change in the behavior of __autoload(), so=
=20
>>that multiple __autoload()'s could be defined.  Essentially, declaring=20
>>__autoload() would in fact add the function to the list of functions that=
=20
>>are called in case a missing class is referenced.  However, it will not=20
>>actually place a function named __autoload() in the PHP function=20
>>table.  That way, it would be possible to declare multiple __autoloads(),=
=20
>>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=
=20
>>__autoload() is declared or not.  I don't think that's a very important=20
>>issue but it's there nonetheless.
>>2.  We need to determine what makes sense as far as calling order if we=20
>>have more than one __autoload().  My guess would be calling them in the=20
>>order they were registered, and checking whether the class was defined=20
>>after each one (if it was - stop).
>>That solution maintains downwards compatibility (almost, other than issue=
=20
>>#1).
>>Thoughts?
>>Zeev
>  Hi Zeev,
>if there will be chained __autoload() functions, isn=B4t it a good idea
>to give to the user the possibility to register autoload funcs like it is
>with the shutdown functions. I think that the user creating the queue is=
 more
>reliable than relying on the include file order except if all the=
 __autoload()
>appear in one file in the sequence they are going to be used. Therefore=
 every
>submodule of a system can register it=B4s own __autoload() which will know=
 how
>to handle the module classes. The handling can be different for another=20
>module.

Why should the order of the queue matter?  Regardless of which solution we=
=20
pick, it will be pretty hellish if the system behaves differently based on=
=20
the order of autoload()'s.  The benefit of using __autoload() is that it's=
=20
downwards compatible.

Zeev