Re: __autoload() enhancement

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