Zeev Suraski wrote:
At 15:18 03/04/2005, Andrey Hristov wrote:
Hi Zeev,
the idea one __autoload() may not be capable of loading therefore the
next
one in the chain should be executed to try to load/define the needed
code.
bool(false) returned from __autoload() means try with the next in the
chain,
bool(true) everything went fine skip the rest of the queue.
What I had in mind (primarily to maintain downwards compatibility), is
that the engine will check whether the class exists after each call to
an autload() callback. If it exists - control returns to the script.
Thatīs ok too.
If it doesn't - the next autoload() is called. That way we don't need
to rely on return values.
Either way, though, the order shouldn't matter...
Zeev
I have seen systems where the include_path is used to overwrite classes.
What do you I mean? There is a core functionality and for a specific project
the core classes can be overwritten by putting them forward in the include_path.
I donīt like this solution but this is probably the only one existing one
and the only one existing for quite a lot of time. If there is ordered execution
of __autload() then the project specific __autoload() will be executed first and
try to load from itīs part if not, returns and __autoload() of the core
will try to load.
I am not a Java profi but I think that Java had similar functionality of
managers
which are organized in a tree structure. Probably we donīt need a tree
structure but
I think the possibility to register own function as autload one is a good idea.
Therefore, instead of allowing the user to define multiple __autoload() he can
do
function thisModule__autoload() {
...
}
register_autoload_function(īthisModule__autoloadī);
Of course one call more, but in the cases one wants to have ordered execution
of the autoload funcs he may implement it. For the people it does not matter it
wonīt make their life harder.
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
