Return-Path: 
 <commons-dev-return-29534-qmlist-jakarta-archive-commons-dev=nagoya.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@apache.org
Received: (qmail 60804 invoked from network); 22 May 2003 21:37:39 -0000
Received: from exchange.sun.com (192.18.33.10)
  by daedalus.apache.org with SMTP; 22 May 2003 21:37:39 -0000
Received: (qmail 23739 invoked by uid 97); 22 May 2003 21:39:54 -0000
Delivered-To: qmlist-jakarta-archive-commons-dev@nagoya.betaversion.org
Received: (qmail 23732 invoked from network); 22 May 2003 21:39:53 -0000
Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12)
  by nagoya.betaversion.org with SMTP; 22 May 2003 21:39:53 -0000
Received: (qmail 60595 invoked by uid 500); 22 May 2003 21:37:37 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:commons-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 60584 invoked from network); 22 May 2003 21:37:37 -0000
Received: from gadolinium.btinternet.com (194.73.73.111)
  by daedalus.apache.org with SMTP; 22 May 2003 21:37:37 -0000
Received: from host217-41-43-8.in-addr.btopenworld.com ([217.41.43.8]
 helo=oemcomputer)
	by gadolinium.btinternet.com with smtp (Exim 3.22 #23)
	id 19Ixks-0007lw-00
	for commons-dev@jakarta.apache.org; Thu, 22 May 2003 22:37:42 +0100
Message-ID: <004201c320ab$4812e480$082b29d9@oemcomputer>
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: 
 <73E71EF16978D51197180002A56022D20743C5C3@ngmnt4mbx03.uk.capitalone.com>
Subject: Re: [collections] simple collections event package + decorators
Date: Thu, 22 May 2003 22:44:11 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

From: "Hope, Matthew" <Matthew.Hope@capitalone.com>
> > IMHO EntryChange is overkill.

> I guess it depends on how much info you want - I see no way with the
previous design to findout exactly what changed without some sort of:
> a) clone the collection prior to any operation and pass the old and the
new
- bleurgh
> b) indicate every single change
>
> If the pupose of the event model is so that something can know that
> *something* changed and vaugely what that change was then EntryChange is
> indeed immense overkill. If the purpose is so that the listener can know
> *what* changed I see no option other than the two above.

For List and Bag, the event as specified should contain enough info to fully
define the changes. For Set everything is troublesome.


> assuming for a moment that the pupose is to know what changed then:
addAll(Collection c)
{
  List changes = new ArrayList(); //of EntryChange
  Iterator iter = c.iterator();
  Object elementToAdd;
  while(iter.hasNext()) {
    elementToAdd = iter.next();
    if (theSet.contains(elementToAdd){
      //do nothing at all with it
    } else {
      theSet.add(elementToAdd);
      changes.add(new EntryChange(elementToAdd, etc...));
    }
  }
}
> <Second code segment cut>

Both code segments presume too much about the Set IMHO. A Set may be defined
to follow the rules in the pseudo-code, but there is no guarantee that the
Set implementation will obey all the rules. The only way to really tell is
to Clone the original state and determine changed events afterwards by
comparing the previous and new states. Which would not be good.

(In case your wondering, a Set that wouldn't work with the rules above is a
PredicatedSet. It doesn't contain the object being added, so the change
event is created, but the add never takes place.)

> what is the rational behind this set of classes? performance? just
> enough info about the change as can be given without significant impact to
> performance? full change info?
>
> If it's the first two then what I'm talking about is clearly a non-starter

I do view it as being low impact, in terms of simple code, few objects
created, small performance impact. Support for more detailed events needs to
be built into the implementation, not added as a decorator IMO.


Also, for the event, I would add
  int oldSize
  int newSize
  boolean sizeChanged
as simple easy to obtain data on the ChangeEvent.

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org