You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Herve Quiroz <he...@esil.univ-mrs.fr> on 2004/04/19 21:00:51 UTC
[events] DynamicProxy decorator
Hi all,
I've realized that using standard decorator pattern usually makes the
"additional" interfaces such as "BoundedCollection" go away in the
process. This means for instance that the CollectionUtils.isFull()
method can no longer use the isFull() method from the object.
You can implement complex decorators to handle that but then each time
you add a new interface to your package, you have to re-implement your
decorators. This is quite not re-usable actually.
Lately, I've implemented an ObservableCollection decorator that is based
upon the dynamic proxy paradigm. With only a few lines of code, this
implementation allows the following:
Buffer buffer=new BoundedFifoBuffer();
ObservableCollection observable=ObservableCollectionUtil.decorate(buffer);
assert observable instanceof Buffer;
assert observable instanceof BoundedCollection;
..where there is no statement regarding Buffer and/or BoundedCollection
in the ObservableCollectionUtil source code.
I thought I could share.
I have the following available:
- interface ObservableCollection
- class ObservableCollectionUtil
- test case ObservableCollectionTest
So far, I have only one kind of event, CollectionIsNoLongerEmptyEvent,
as it is the only one I needed for my own package. However, if you feel
interested by my contribution, I can provide addtional events, or
refactor my classes to match one of the existing event models from
[events].
I also need observable functors for my own code, so chances are I will
implement them as well. Same goes here: if you're interested, please
tell me so we can plan things in advance and I don't need to refactor
the classes to donate them to Apache...
Tell me if you want to have a look at the classes, and I will post a
link on my homepage.
Herve
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [events] DynamicProxy decorator
Posted by Michael Heuer <he...@acm.org>.
On Tue, 20 Apr 2004, Herve Quiroz wrote:
> Thanks for the link Michael.
>
> I like the API in nettool, as it is quite generic. I think however that
> such a package will require a tutorial to get people started as
> genericity often comes to a price of complexity.
>
> Regarding your alternative, do you have API docs available? It's quite
> difficult to browse the source (especially in a CVS web interface).
Sorry, I don't have a real good place to host the javadocs for browsing.
You'll either have to use cvs to check out the source and run maven
javadoc or download
> http://shore.net/~heuermh/dsh-observable-javadocs.tar.gz
There are still a few TODOs, mostly related to Iterator-remove-from-
entrySet-view-on-SortedBidiMap like complexity discussed recently.
michael
>
> Herve
>
> PS: I do remember now that such discussion occured last year. That's
> mostly why I wonder why [events] is not more active now that it is a
> standalone project...
>
> On Tue, Apr 20, 2004 at 12:12:00PM -0400, Michael Heuer wrote:
> > Hello Herve,
> >
> > You might also want to take a look at
> >
> > > http://nettool.sourceforge.net/nc
> >
> > and
> >
> > > https://dsh-lib.dev.java.net/source/browse/dsh-lib/observable/
> >
> > These are alternate designs for collections events, discussed on the
> > commons-dev mailing list back about June of last year.
> >
> > michael
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [events] DynamicProxy decorator
Posted by Herve Quiroz <he...@esil.univ-mrs.fr>.
Thanks for the link Michael.
I like the API in nettool, as it is quite generic. I think however that
such a package will require a tutorial to get people started as
genericity often comes to a price of complexity.
Regarding your alternative, do you have API docs available? It's quite
difficult to browse the source (especially in a CVS web interface).
Herve
PS: I do remember now that such discussion occured last year. That's
mostly why I wonder why [events] is not more active now that it is a
standalone project...
On Tue, Apr 20, 2004 at 12:12:00PM -0400, Michael Heuer wrote:
> Hello Herve,
>
> You might also want to take a look at
>
> > http://nettool.sourceforge.net/nc
>
> and
>
> > https://dsh-lib.dev.java.net/source/browse/dsh-lib/observable/
>
> These are alternate designs for collections events, discussed on the
> commons-dev mailing list back about June of last year.
>
> michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [events] DynamicProxy decorator
Posted by Michael Heuer <he...@acm.org>.
Hello Herve,
You might also want to take a look at
> http://nettool.sourceforge.net/nc
and
> https://dsh-lib.dev.java.net/source/browse/dsh-lib/observable/
These are alternate designs for collections events, discussed on the
commons-dev mailing list back about June of last year.
michael
On Tue, 20 Apr 2004, Herve Quiroz wrote:
> Stephen,
>
> Here it is:
> http://www.esil.univ-mrs.fr/~hquiroz/mupisim-event-20040420.tgz
>
> Basically, some classes or interfaces need to be renamed but I'll
> refactor this another day:
>
> -> "EventSource" should be "Observable"
>
> I adopted a special event framework, or at least it is quite different
> from the one you chose within [events]. Basically, I have one interface
> for any event observer, called EventListener (just as in the standard
> API). The only method is:
>
> public void processEvent(EventObject event);
>
> You will note that I use a generic event class, also provided by the
> standard API.
>
> [ Damn! the site is broken... I can't have a look at [events] JavaDoc ]
>
> I quite don't like when event identification is based on integers or
> strings. I like to have them identified by their class or the interfaces
> they implement. Maybe I'm totally wrong here, so please tell me if you
> disagree (and most of all, tell me why). Here we have:
>
> EventObject
> `- CollectionEvent
> `- CollectionIsNoLongerEmptyEvent
>
> Hence, an event listener may process events from multiple sources (with
> different classes) through one method: processEvent. Here is an example:
>
> public void processEvent(EventObject event)
> {
> if (event instanceof CollectionIsNoLongerEmptyEvent)
> {
> System.out.println("Hum. I can get something from this collection");
> }
> if (event instanceof UniverseHasCollapsedEVent)
> {
> System.out.println("Hum. That does not sound good");
> }
> }
>
> If you want to bundle extra information regarding the event (e.g. how
> many elements were added at once), it is possible: you implement it in
> your specific event class. Then by casting 'event', an event listener
> may retrieve this information.
>
> You'll see also that proxy deprecate the need of specific Observable
> interface such as ObservableBuffer, ObservableSet, etc...
>
> Well, that's it for now.
>
> Herve
>
>
> On Mon, Apr 19, 2004 at 08:19:27PM +0100, Stephen Colebourne wrote:
> > I always welcome the chance to look at some code ;-) I can't promise to
> > integrate it, as my time has been limited of late, but it may benefit
> > others. [events] is another project where there is a good idea, and
> > potential for reusable code, but it lacks committers other than me :-(
> >
> > Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [events] DynamicProxy decorator
Posted by Herve Quiroz <he...@esil.univ-mrs.fr>.
Stephen,
Here it is:
http://www.esil.univ-mrs.fr/~hquiroz/mupisim-event-20040420.tgz
Basically, some classes or interfaces need to be renamed but I'll
refactor this another day:
-> "EventSource" should be "Observable"
I adopted a special event framework, or at least it is quite different
from the one you chose within [events]. Basically, I have one interface
for any event observer, called EventListener (just as in the standard
API). The only method is:
public void processEvent(EventObject event);
You will note that I use a generic event class, also provided by the
standard API.
[ Damn! the site is broken... I can't have a look at [events] JavaDoc ]
I quite don't like when event identification is based on integers or
strings. I like to have them identified by their class or the interfaces
they implement. Maybe I'm totally wrong here, so please tell me if you
disagree (and most of all, tell me why). Here we have:
EventObject
`- CollectionEvent
`- CollectionIsNoLongerEmptyEvent
Hence, an event listener may process events from multiple sources (with
different classes) through one method: processEvent. Here is an example:
public void processEvent(EventObject event)
{
if (event instanceof CollectionIsNoLongerEmptyEvent)
{
System.out.println("Hum. I can get something from this collection");
}
if (event instanceof UniverseHasCollapsedEVent)
{
System.out.println("Hum. That does not sound good");
}
}
If you want to bundle extra information regarding the event (e.g. how
many elements were added at once), it is possible: you implement it in
your specific event class. Then by casting 'event', an event listener
may retrieve this information.
You'll see also that proxy deprecate the need of specific Observable
interface such as ObservableBuffer, ObservableSet, etc...
Well, that's it for now.
Herve
On Mon, Apr 19, 2004 at 08:19:27PM +0100, Stephen Colebourne wrote:
> I always welcome the chance to look at some code ;-) I can't promise to
> integrate it, as my time has been limited of late, but it may benefit
> others. [events] is another project where there is a good idea, and
> potential for reusable code, but it lacks committers other than me :-(
>
> Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [events] DynamicProxy decorator
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I always welcome the chance to look at some code ;-) I can't promise to
integrate it, as my time has been limited of late, but it may benefit
others. [events] is another project where there is a good idea, and
potential for reusable code, but it lacks committers other than me :-(
Stephen
----- Original Message -----
From: "Herve Quiroz" <he...@esil.univ-mrs.fr>
> I've realized that using standard decorator pattern usually makes the
> "additional" interfaces such as "BoundedCollection" go away in the
> process. This means for instance that the CollectionUtils.isFull()
> method can no longer use the isFull() method from the object.
>
> You can implement complex decorators to handle that but then each time
> you add a new interface to your package, you have to re-implement your
> decorators. This is quite not re-usable actually.
>
> Lately, I've implemented an ObservableCollection decorator that is based
> upon the dynamic proxy paradigm. With only a few lines of code, this
> implementation allows the following:
>
>
> Buffer buffer=new BoundedFifoBuffer();
> ObservableCollection observable=ObservableCollectionUtil.decorate(buffer);
>
> assert observable instanceof Buffer;
> assert observable instanceof BoundedCollection;
>
>
> ..where there is no statement regarding Buffer and/or BoundedCollection
> in the ObservableCollectionUtil source code.
>
>
> I thought I could share.
>
> I have the following available:
>
> - interface ObservableCollection
> - class ObservableCollectionUtil
> - test case ObservableCollectionTest
>
> So far, I have only one kind of event, CollectionIsNoLongerEmptyEvent,
> as it is the only one I needed for my own package. However, if you feel
> interested by my contribution, I can provide addtional events, or
> refactor my classes to match one of the existing event models from
> [events].
>
> I also need observable functors for my own code, so chances are I will
> implement them as well. Same goes here: if you're interested, please
> tell me so we can plan things in advance and I don't need to refactor
> the classes to donate them to Apache...
>
> Tell me if you want to have a look at the classes, and I will post a
> link on my homepage.
>
> Herve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [events] DynamicProxy decorator
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I've implemented an ObservableCollection decorator that is
> based upon the dynamic proxy paradigm. With only a few lines of
> code, this implementation allows the following:
> Buffer buffer=new BoundedFifoBuffer();
> ObservableCollection observable=ObservableCollectionUtil.decorate(buffer);
> assert observable instanceof Buffer;
> assert observable instanceof BoundedCollection;
> I thought I could share.
Serendipitously, Stephen Colebourne was just looking at a very similar issue
(serializable decoractors), and might find your approach interesting.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org