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] Created: (SANDBOX-149) [events] Notifying/Observable Design Choice
Date Tue, 13 Jun 2006 22:09:31 GMT
[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


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