Re: PEAR_Autoloader

On Tuesday, Oct 28, 2003, at 18:13 America/New_York, Bertrand Mansion wrote:

An object can only have one delegate, so your method should be setDelegate(), not addDelegate().

You are right with respect to the idea of delegates, but I originally implemented (or enhanced) the aggregation of the methods so that they would act like interfaces (this was prior to PHP 5). In other words, multiple inheritance of methods is possible (though without the niceness of language support in determining the inheritance--things like instanceof--though methods could be used). Multiple delegates allow a class to inherit properly from the actual hierarchy and still have extra functionality. Sometimes there are methods that are useful in subclasses that should not be logically derived from the same superclass or some other combination that requires extra functionality that can't be handled through inheritance. This is where interfaces are helpful, but interfaces require each object to implement the methods, and if the methods are often implemented in the same way, it becomes more of a hassle than a help.

Also, I am not sure it's a good idea to set a owner in the delegate, after all, the delegate shouldn't care who's its owner. Then hello() could be hello($owner), but I think that having the delegate modify its owner is probably not a good thing, just a feeling I have. I see a delegate as a slave. The slave can't change the master.

There are, of course, security issues with this kind of added functionality, but those are generally only going to be on the server side, it would seem, and were already present most likely. The idea of passing objects in each of the methods of the delegate is interesting, but cumbersome, and you will notice that it is similar to method calls anyway where a reference to the object is transparently passed with each call, so it makes more sense for the delegate to automatically know who owns it. The way I implemented it, only the class is passed in as the source of the delegate, so its not to much like an object being created and specified to be the delegate, although that might be useful too. Also, it's not so much a slave-master relationship, although it could be used as such. In fact, that is what PEAR_Autoloader does, because it provides no way of setting the owner.

I am also not sure an owner needs to know about all the methods in its delegate, I think it should just test if a method_exists() in the delegate before calling that method. An owner could probably have a special instance var with the delegate methods it is likely to call.

I thought of this feature as more of a help to the programmer than to the object, so it is usually the programmer who will decide which delegate is best to use based on its abilities, and there is no reason why an object should not know all of its delegates' methods. If you are talking about the implementation of the method-->delegate lookup tables, that was implemented by the PEAR_Autoloader class, and I just added some to it. It probably is a little quicker than asking each delegate if it can do a method. Nevertheless, I don't see why that couldn't be reimplemented in the __call() method, so that methods aren't recorded, there just found and executed by the first one that can. NOTE: I was a little incorrect in my presentation of the code, because I had to modify the Autoloader.php file to get it to work with PHP 5. I had to fix the __call() method, which was no bigee (see the bug report I posted, if you like). I hope I have made some sense. Thanks for your response.

Delegates would be a really cool addition to PHP.

I agree!

Bertrand Mansion Mamasam