Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of craigmcc@gmail.com designates
 64.233.170.200 as permitted sender)
Message-ID: <f8b39ace04100409383d8fa977@mail.gmail.com>
Date: Mon, 4 Oct 2004 09:38:37 -0700
From: Craig McClanahan <craigmcc@gmail.com>
Reply-To: Craig McClanahan <craigmcc@gmail.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>,
	mstanley@mstanley.net
Subject: Re: sandbox proposal. Events
In-Reply-To: <1096903155.17783.142.camel@godel.cauldronsolutions.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <1096903155.17783.142.camel@godel.cauldronsolutions.com>

Mike,

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.

Craig


On Mon, 04 Oct 2004 11:19:15 -0400, Mike Stanley <mstanley@mstanley.net> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org