commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hope, Matthew" <Matthew.H...@capitalone.com>
Subject RE: [collections] simple collections event package + decorators
Date Fri, 23 May 2003 09:17:36 GMT

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: 22 May 2003 22:44
> To: Jakarta Commons Developers List
> Subject: Re: [collections] simple collections event package + 
> decorators
> For List and Bag, the event as specified should contain 
> enough info to fully
> define the changes. For Set everything is troublesome.

This is true - just work off what can be done simply/quickly makes sense.

> 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.

fair point - how about

 addAll(Collection c)
 {
   List changes = new ArrayList(); //of EntryChange
   Iterator iter = c.iterator();
   Object elementToAdd;
   while(iter.hasNext()) {
     elementToAdd = iter.next();
     if (theSet.contains(elementToAdd){
       //do nothing at all with it
     } else {
       theSet.add(elementToAdd);
	 if (theSet.contains(elementToAdd)) {
         changes.add(new EntryChange(elementToAdd, etc...));
       }
     }
   }
 }

Though I suppose you could keep coming up with examples of sets which don't
'behave'
 
> (In case your wondering, a Set that wouldn't work with the 
> rules above is a PredicatedSet.

solution (I think) albeit more complex still above but given...
 
> 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.

fair enough - my ideas are just going against the raison d'etre which is
silly. I might have a play around with it myself and see where (not if :¬) I
hit a brick wall
 
 
> Also, for the event, I would add
>   int oldSize
>   int newSize
>   boolean sizeChanged
> as simple easy to obtain data on the ChangeEvent.

I would make the boolean an inferred value only when hasSizeChanged() (or
whatever) is called. it will likely only ever be called the once so delay
the calculation unless it is needed and reduce the memory footprint of the
class by a few bits :¬)

Matt
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

---------------------------------------------------------------------
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