commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [collections] simple collections event package + decorators
Date Thu, 22 May 2003 21:44:11 GMT
From: "Hope, Matthew" <>
> > IMHO EntryChange is overkill.

> I guess it depends on how much info you want - I see no way with the
previous design to findout exactly what changed without some sort of:
> a) clone the collection prior to any operation and pass the old and the
- bleurgh
> b) indicate every single change
> If the pupose of the event model is so that something can know that
> *something* changed and vaugely what that change was then EntryChange is
> indeed immense overkill. If the purpose is so that the listener can know
> *what* changed I see no option other than the two above.

For List and Bag, the event as specified should contain enough info to fully
define the changes. For Set everything is troublesome.

> assuming for a moment that the pupose is to know what changed then:
addAll(Collection c)
  List changes = new ArrayList(); //of EntryChange
  Iterator iter = c.iterator();
  Object elementToAdd;
  while(iter.hasNext()) {
    elementToAdd =;
    if (theSet.contains(elementToAdd){
      //do nothing at all with it
    } else {
      changes.add(new EntryChange(elementToAdd, etc...));
> <Second code segment cut>

Both code segments presume too much about the Set IMHO. A Set may be defined
to follow the rules in the pseudo-code, but there is no guarantee that the
Set implementation will obey all the rules. The only way to really tell is
to Clone the original state and determine changed events afterwards by
comparing the previous and new states. Which would not be good.

(In case your wondering, a Set that wouldn't work with the rules above is a
PredicatedSet. It doesn't contain the object being added, so the change
event is created, but the add never takes place.)

> what is the rational behind this set of classes? performance? just
> enough info about the change as can be given without significant impact to
> performance? full change info?
> If it's the first two then what I'm talking about is clearly a non-starter

I do view it as being low impact, in terms of simple code, few objects
created, small performance impact. Support for more detailed events needs to
be built into the implementation, not added as a decorator IMO.

Also, for the event, I would add
  int oldSize
  int newSize
  boolean sizeChanged
as simple easy to obtain data on the ChangeEvent.


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

View raw message