Re: MethodClosure (BCEL Delegator implementation)

[Leo Sutic]

Hi Chris!

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:

1. The resulting delegate class must implement equals() in the same way as the Excalibur delegate.

2. I lack the MultiDelegate from Excalibur.

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?

4. Javadocs. I'm sure the MethodClosure class is equivalent, so you could probably just copy the javadoc from Excalibur.

5. I'm not sure I like the fact that the delegate object also doubles as a factory. You can get method signature collisions.

(If I'm wrong on any point above I apologize. I haven't had time for a thorough review of the code.)

/LS


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>