[jira] Commented: (SANDBOX-149) [events] Notifying/Observable Design Choice

["Bryce Nordgren (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/SANDBOX-149?page=comments#action_12416246 ] 

Bryce Nordgren commented on SANDBOX-149:
----------------------------------------

Is there any reason not to consider "ModificationEvents" to be a specialization of property change events?  There could be a property called "contents" for collection types to which clients could subscribe.  If people want "special" events, they could subclass PropertyChangeEvents and PropertyChangeSupport.

Additionally, is there any need for pre and post change events if Vetoable changes are properly supported?  I think most of the logic for this sort of thing is implemented in java.beans and doesn't need to be reinvented here...

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