PEAR_DelegateOwner Part Deux
| From: | lingwitt at bellsouth dot net | Date: | Mon, 12 Jan 2004 22:15:18 +0000 |
| Subject: | PEAR_DelegateOwner Part Deux | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-25020@lists.php.net to get a copy of this message | ||
I had ventured to promote this class earlier, and I got some good reviews and some bad. I
have continued to sculpt the concept, and the class now sports the following features:
****The Traditional Delegate Model:
The traditional model of delegation is that an object delegates selected methods, calling its
own version unless one delegate is present. This is now possible as a built in feature that
simply limits the the overall capabilities of the class.
****Delegate hierarchies:
That is, a delegate owner could have a delegate that is a delegate owner, and the
PEAR_DelegateOwner class recognizes this by viewing such delegates as subdelegates,
treating such subdelegates as subclasses would be treated. This allows for such capabilities
as pseudo-overriding.
****Static and Dynamic Delegates:
Delegates can be either class objects or instantiated classes. If a delegate uses
instance variables, then it should be added as an object. If it simply provides
methods that call upon the owner's variables or that could be called statically, it should
be added as a class; moreover, adding static (class) delegates obviates the waste associated
with instantiating an object each time a delegate type is used.
****Error Messages:
It was of major concern to some that the debugging of a delegate owner would be atrocious. This
has been solved with extremely helpful error messages based on those of PHP. If an error is
produced, the message will contain the file, line, and error in which the user of the code made the
mistake of adding a nonexistent class or calling an unimplemented method.
Possible Problems:
The code (including documentation) is approximately 1345 lines, which some may consider
bloated. All of this is currently in one file, but due to the nature of the class, I can actually split it
into delegates that can be loaded transparently.
Moreover, the error producing code is a bit heavy-handed, as it needs to be specific, and some may say that it should be lighter. I can't see how to make it lighter and as useful.
Please give me your thoughts,
Herr Witten