commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryce Nordgren (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SANDBOX-149) [events] Notifying/Observable Design Choice
Date Wed, 14 Jun 2006 19:25:31 GMT
     [ http://issues.apache.org/jira/browse/SANDBOX-149?page=all ]

Bryce Nordgren updated SANDBOX-149:
-----------------------------------

    Attachment: Observable.png

UML Diagram of the current code in the events package.

> [events] Notifying/Observable Design Choice
> -------------------------------------------
>
>          Key: SANDBOX-149
>          URL: http://issues.apache.org/jira/browse/SANDBOX-149
>      Project: Commons Sandbox
>         Type: Task

>     Reporter: Bryce Nordgren
>     Priority: Blocker
>  Attachments: Observable.png
>
> Prior to retiring the events package a couple of years ago, three different design options
were articulated.  One option needs to be selected prior to expending further work.  Note
that the code in the repository has a modification date somewhere in early 2005, after this
message was written.  I believe that the code in the repository reflects a modified version
of #3.  Choice #3 seems like the most logical to me.
> The email is located here: 
> http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200306.mbox/%3c007801c32d17$3fdaafa0$083b29d9@oemcomputer%3e
> {quote}
> 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
> {quote}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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