commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From _matthewHawthorne <mhawtho...@alumni.pitt.edu>
Subject Re: [collections] Notifying/Observable design choices
Date Sat, 07 Jun 2003 19:18:25 GMT
I haven't been involved in the discussion, but on first glance, I give
Proposal #3 a +1... since it seems to allow for flexibility in event
data, exception handling, and performance by creating subclasses.


On Sat, 2003-06-07 at 10:07, Stephen Colebourne wrote:
> Three possible designs (so far):
> 
> Proposal #1 (Heuer/MailingList)
> --------------------------------
> public boolean addAll(int index, Collection coll) {
>   int oldSize = backingList.size();
>   boolean returnVal = backingList.addAll(index, coll);
>   int newSize = backingList.size();
>   if (returnVal) {
>     CollectionChangeEvent e = new
> CollectionChangeEvent(this,oldSize,newSize,index,coll.size(),null,coll,true)
> ;
>     support.fireElementsAdded(e);
>   }
>   return returnVal;
> }
> - One Event class.
> - Event data chosen by us (so less flexible).
> - Should handle all collections, but iterators will not be fail-fast.
> - Should give reasonable performance.
> - Relies on accurate result boolean.
> - Relatively few classes
> 
> 
> Proposal #2 (O'Toole):
> -------------------------
> public boolean addAll(int index, Collection c){
>   this.throwIfIndexOutOfBoundsExclusive(index);
>   ModifyingCollectionEvent event =
> this.listEventFactory.createAddAllEvent(index, c);
>   this.doFireVetoableEvent(event); // can throw a
> CollectionModificationVetoedException
>   boolean result = backingList.addAll(index, c);
>   if (result){
>    this.incrementModCount();
>    this.doFirePostModificationEvent(event);
>   }
>   return result;
>  }
> - Event implementation class chosen by factory.
> - Event data is theoretically flexible, but limited in practice. In
> particular, the post-event cannot contain a copy of the state of the
> collection, or the size before the change occurred (ie. you can't replicate
> proposal #1)
> - Unsuited to certain collections (eg. LazyList)
> - Should give reasonable performance.
> - Relies on accurate result boolean.
> - Exception thrown from vetoed pre-events.
> - Quite a lot of classes and concepts
> 
> 
> Propsal #3 (Colebourne - merged from #1 and #2):
> --------------------------
> public boolean addAll(int index, Collection c){
>   if (preAddAll(index, c)) {
>     result = backingList.addAll(index, c);
>     postAddAll(index, c, result);
>   }
>   return result;
>  }
> - Event implementation class chosen by subclass.
> - Event data can be chosen by subclass.
> - Should handle all collections, but iterators will not be fail-fast
> (although subclass could include coding for that...).
> - Will perform as per how you write the subclass. (Faster or slower)
> - Subclass can choose whether to believe boolean result.
> - Subclass can choose whether to use Listener pattern, or something else
> (eg. call a static method)
> - Choice of exception or ignore for vetoed pre-events.
> - Relatively few classes, but subclasses may get have more classes
> 
> 
> #3 explanation:
> The class gets changed into an abstract one, with a real implementation or
> two supplied in [collections]. Thus, AbstractNotifyingList would have the
> method above, with NotifyingList as a subclass, managing event creation and
> dispatch (using convenience methods from the abstract class.
> 
> 
> Any comments, views or opinions on the three designs???
> I guess I believe that #3 is the best compromise between #1 and #2 I can
> think of (both #1 and #2 can be built using #3).
> 
> 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


Mime
View raw message