commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryce Nordgren (JIRA)" <>
Subject [jira] Commented: (SANDBOX-149) [events] Notifying/Observable Design Choice
Date Sat, 24 Jun 2006 01:08:32 GMT
    [ ] 

Bryce Nordgren commented on SANDBOX-149:

Partially executed the design of the previous comment.  The "Observable" problem has been
recast in terms of the more familiar (to me) java event pattern: a listener interface, an
event, and a listener registry mechanism.  The design has evolved somewhat from the UML diagrams
on this page, such that BoundCollections directly use the event factories.  

The result of this is something that's easier for me to get my mind around.  In particular,
when "subLists", "subSets" and "subMaps" are made (all of which are views to a common aggrecation
of data items), I believe this is a much more straightforward way to ensure that all registered
listeners for all the views get an event for a change caused by any view.

I have produced a BoundMap, as well, which is not included in the original (dormant) code.

Interested parties can check out the code as it is from the GeoTools subversion server.  It
needs more work before it is complete enough to attach to this issue, but a quick checkout
should give an idea of what has been done.

For something that compiles with maven 2:
For just the commons-events source:

> [events] Notifying/Observable Design Choice
> -------------------------------------------
>          Key: SANDBOX-149
>          URL:
>      Project: Commons Sandbox
>         Type: Task

>     Reporter: Bryce Nordgren
>     Priority: Blocker
>  Attachments: Observable.png, UsingPropertyChangeSupport.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: 
> {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:
For more information on JIRA, see:

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

View raw message