On Sat, Dec 21, 2002, Leo Sutic wrote: > I took a look at your MethodClosure implementation, and it is very > interesting. I had hoped that Excalibur's delegate framework would have > moved into another project by now (I was hoping for Commons/Lang), and I > can't wait to clean out the code from the Excalibur CVS. So just the fact > that there is a delegate framework in a project that is "big enough" to > have a community to support it is great. That it beats the current > implementation speed-wise without any other tradeoffs is excellent. > > However, I have some issues with the way it is implemented now that have to > be solved before it can completely replace the Excalibur implementation:
No problem, the feedback is appreciated. To be clear, replacing the Excalibur implemenation wasn't my primary goal. I thought the basic Delegate idea had merit, and was curious how much faster it could be. (Also I just enjoy writing bytecode, but don't tell anyone that :-) I'm happy to make it compatible as far as makes sense, though. > 1. The resulting delegate class must implement equals() in the same way as > the Excalibur delegate. I've added this. Is it correct that you could have two equal delegates that implement different interfaces? > 2. I lack the MultiDelegate from Excalibur. Yes, I have to think more about that. The advantages will not be quite as great, since you'll have to loop over the list of registered listeners in either case. > 3. I don't understand the MethodClosureKey interface. Is this a way to get > a new delegate with the same signature, but pointing to another instance of > the handling class? (I.e. a clone() equivalent) If so, why is the first > parameter a Class and not an Object? MethodClosureKey should be a package-protected interface, but that causes problems under JDK1.2. It is used internally to maintain a cache of generated MethodClosure classes (see the KeyFactory class for more info). > 4. Javadocs. I'm sure the MethodClosure class is equivalent, so you could > probably just copy the javadoc from Excalibur. Can't argue with this one. > 5. I'm not sure I like the fact that the delegate object also doubles as a > factory. You can get method signature collisions. I've changed the code so that you'll get a ClassCastException if you make a newInstance of the wrong type (before it was deferred until you invoked the delegate). The method is used internally to generate new instances from cached factory versions of the delegates. It could be made a protected method, but I think it can be useful as a public API too (faster than going through the cache). I'm not set on this though. Thanks, Chris -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
