commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: sandbox proposal. Events
Date Mon, 04 Oct 2004 16:38:37 GMT

This pattern does indeed sound interesting.  You might also want to
take a look at the [pipeline] sandbox package (contributed by Kris
Nuttycombe) that I checked in over the weekend.  It offers a different
tack on handling asynchronous events, and is also investigating how an
interaction with [chain] might be beneficial.

>From a practical perspective, there exists already a sandbox package
named [events], originally extracted from [collections].  I haven't
been tracking whether this is actually active or not; if so, we'd need
to use some different top level name for the package itself.


On Mon, 04 Oct 2004 11:19:15 -0400, Mike Stanley <> wrote:
> I've implemented a pattern, somewhat based off the .NET event and
> delegate pattern, however the pattern is also commonly seen in
> frameworks (to some extent).
> At a high level, the pattern is made up of two objects:
> - Event
> - DelegateMethod
> The Event is a container for DelegateMethods.  Delegate Methods are
> registered with the Event (added to the container).  The first delegate
> method added to the container determines the contract for that event.
> I.e. each method added must have similar signatures (take the same
> number and types of parameters and return the same type).  At any time
> the event can be fired.  When an event is fired it invokes the delegate
> methods in the order they were added.  The event can be configured to
> fail on first exception, or continue without failing.  If the delegate
> methods return a value, the last value would be returned (this is the
> behavior of the .NET approach.  I'm open to other suggestions).
> A Delegate Method gets created with an instance of an object and the
> name of the method (optionally when instantiating the Delegate Method
> you may specify the signature - or actual Method, in the case that there
> are multiple methods with the same name but different signatures).  This
> method will be invoked using reflection (delegateMethod.invoke(args))
> when the event is fired.
> At it's core this is the basic idea.  Above this, there are (*plans*) to
> create Asynchronous Delegate Methods and events, providing simple
> support for multi-threaded events.  This will use the same concepts from
> .NET (callbacks, begin invokes, end invokes, async results, etc).
> I'm also investigating migrating the pattern to utilize "commons-chain".
> Currently this does not exist as a stand-alone library.  However, if
> there is interest, I will begin to pull it out and contribute it to the
> commons-sandbox.
> - Mike

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message