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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
