You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2003/05/24 12:55:28 UTC
[collections] Observable next steps
Proposed design:
CollectionListener class:
elementsAdded(CollectionChangeEvent)
elementsRemoved(CollectionChangeEvent)
elementsChanged(CollectionChangeEvent)
CollectionChangeEvent:
Collection collection - the collection (current reference, ie. after
change)
int numberChanged - the number of elements changing
int changeIndex - for Lists, the index where the change starts
Object changed - the value/collection being added/removed/changed
boolean bulkOperation - true if addAll() etc. or clear()
int oldSize - size before change
int newSize - size after change
boolean sizeChanged - (derived from previous two)
Maps would have their own listener and event.
Michael, you submitted a lot of code that could be extended to form this
design. Are you able and willing to do the work?
Notes:
- A second decorator() method should be added that takes in a Listener
- The decorator() methods should return ObservableXxx.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Observable next steps
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Michael Heuer" <he...@acm.org>
> On Sat, 24 May 2003, Stephen Colebourne wrote:
>
> > CollectionChangeEvent:
> > Collection collection - the collection (current reference, ie. after
> > change)
> > int numberChanged - the number of elements changing
> > int changeIndex - for Lists, the index where the change starts
> > Object changed - the value/collection being added/removed/changed
> > boolean bulkOperation - true if addAll() etc. or clear()
> > int oldSize - size before change
> > int newSize - size after change
> > boolean sizeChanged - (derived from previous two)
>
> It looks to me that collecting this information may require
> synchronization in the decorator -- is that acceptable?
>
> ObservableCollection
> extends AbstractCollectionDecorator
>
> public boolean add(Object object)
> {
> // synchronized {
>
> int oldSize = size();
> boolean returnVal = super.add(object);
> int newSize = size();
>
> // }
>
> if (returnVal)
> support.fireElementAdded(oldSize, newSize, object);
>
> return returnVal;
> }
>
Synchronization is not the concern of the Observable classes. The user must
synchronize themselves if it is important.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Observable next steps
Posted by Michael Heuer <he...@acm.org>.
On Sat, 24 May 2003, Stephen Colebourne wrote:
> CollectionChangeEvent:
> Collection collection - the collection (current reference, ie. after
> change)
> int numberChanged - the number of elements changing
> int changeIndex - for Lists, the index where the change starts
> Object changed - the value/collection being added/removed/changed
> boolean bulkOperation - true if addAll() etc. or clear()
> int oldSize - size before change
> int newSize - size after change
> boolean sizeChanged - (derived from previous two)
It looks to me that collecting this information may require
synchronization in the decorator -- is that acceptable?
ObservableCollection
extends AbstractCollectionDecorator
public boolean add(Object object)
{
// synchronized {
int oldSize = size();
boolean returnVal = super.add(object);
int newSize = size();
// }
if (returnVal)
support.fireElementAdded(oldSize, newSize, object);
return returnVal;
}
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Observable next steps
Posted by "Michael L. Heuer" <he...@acm.org>.
On Sat, 24 May 2003, Stephen Colebourne wrote:
> Proposed design:
>
> CollectionListener class:
> elementsAdded(CollectionChangeEvent)
> elementsRemoved(CollectionChangeEvent)
> elementsChanged(CollectionChangeEvent)
>
> CollectionChangeEvent:
> Collection collection - the collection (current reference, ie. after
> change)
> int numberChanged - the number of elements changing
> int changeIndex - for Lists, the index where the change starts
> Object changed - the value/collection being added/removed/changed
> boolean bulkOperation - true if addAll() etc. or clear()
> int oldSize - size before change
> int newSize - size after change
> boolean sizeChanged - (derived from previous two)
>
> Maps would have their own listener and event.
>
> Michael, you submitted a lot of code that could be extended to form this
> design. Are you able and willing to do the work?
>
> Notes:
> - A second decorator() method should be added that takes in a Listener
> - The decorator() methods should return ObservableXxx.
This sounds pretty reasonable.
I'll flesh out what I currently have with the changes to the listener and
event classes and the decorator methods and post a new source tarball in a
few days.
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org