BCEL multicasting delegate implementation

[Chris Nokleberg <ch...@sixlegs.com>]

I've checked in a MulticastDelegate class to CGLIB CVS
(cglib.sf.net). MethodClosure has been renamed MethodDelegate, and now
supports delegating to static methods. Both use BCEL to generate dynamic
classes on the fly when needed.

MulticastDelegate is patterned more closely after the C# version than
the one currently in Avalon:

- The objects are immutable. "add" and "remove" return a new object
  rather than mutating the existing one. This helps with thread safety,
  among other things.

- You can add a delegate to a MulticastDelegate multiple times. The
  delegate will be called once for each time it appears in the
  multicaster's invocation list. This seemed more flexible to me, and
  client code can enforce the set-like semantics when necessary.

As suggested, I've been copying over some of the documentation from the
Avalon classes. If anyone has a problem with this, let me know. I wasn't
sure whether to leave the @author tags or not, so for now they are still
there.

Regards,
Chris



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: BCEL multicasting delegate implementation

[Berin Loritsch <bl...@citi-us.com>]

> From: Chris Nokleberg [mailto:chris@sixlegs.com]
> 
> I've checked in a MulticastDelegate class to CGLIB CVS
> (cglib.sf.net). MethodClosure has been renamed MethodDelegate, and now
> supports delegating to static methods. Both use BCEL to 
> generate dynamic
> classes on the fly when needed.
> 
> MulticastDelegate is patterned more closely after the C# version than
> the one currently in Avalon:
> 
> - The objects are immutable. "add" and "remove" return a new object
>   rather than mutating the existing one. This helps with 
> thread safety,
>   among other things.
> 
> - You can add a delegate to a MulticastDelegate multiple times. The
>   delegate will be called once for each time it appears in the
>   multicaster's invocation list. This seemed more flexible to me, and
>   client code can enforce the set-like semantics when necessary.
> 
> As suggested, I've been copying over some of the 
> documentation from the
> Avalon classes. If anyone has a problem with this, let me 
> know. I wasn't
> sure whether to leave the @author tags or not, so for now 
> they are still
> there.

When donating code/interfaces, keeping the @author tags is a good thing.
If the Delegate stuff works well, then use the javadocs as we have them
(modifying to suite the difference in multi-delegate).

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>