commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections][lang] submission: NotifyingCollections (observable) / o.a.c.l.event
Date Sat, 07 Jun 2003 17:05:18 GMT
From: "Neil O'Toole" <neilotoole@users.sourceforge.net>
> - Decorators for Collection, List, and Set (NotifyingCollection,
> NotifyingList, NotifyingSet).
I would like our end solution to cover the Bag, SortedSet and SortedBag
interfaces too.

> - Two types of notification: "post-modification" (or 'historical')
> notification, and "pre-modification" (or 'vetoable') notification.
> Pre-modification events can be vetoed before the actual modification
> occurs (similar to the bean VetoableChangeListener).
My first reaction was that this was covered by Predicated collections that
validate the object being added, but this gives more details.

> - Pluggable events: NotifyingCollections uses a pluggable event
> factory,
...
> A default event package is provided, in
> the org.apache.commons.collections.notifying.detailed package. This
> "detailed" event package is a quite heavyweight event system that
> provides detailed information on modifications to the collection.
We should supply a simple implementation too.

I think that this has the basis to be a good implementation. Some comments:
1) I dislike that a new instance of the event factory has to be created for
each collection. The factory should be capable of being shared. This can be
done by passing the init() parameters to each of the other methods.

2) The event dispatch sometimes assumes too much. For example the List
addAll() method validates the index as being in range, but the LazyList
implementation expects out of range indices. The modCount in the iterators
could face the same problem.

3) Similar to (2), the boolean result flag cannot be relied on to give
accurate results as to whether the collection has changed.

4) What if I want vetos to have no effect, rather than throw an exception.

5) It is quite hard to get info out about events. Typecasting is always
needed.

6) There are a lot of classes to get your head around - its very OO.

(2) - (5) give me pause to think about an alternative design... See separate
thread.

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message