PEAR_DelegateOwner Part Deux

From: 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

« previous php.pear.dev (#25020) next »