commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <pj...@sfaf.org>
Subject RE: [Commons-Avalon:collections] Buffer integration [was: code in tegration]
Date Tue, 25 Jun 2002 18:14:00 GMT
> Buffers/Queues/Stacks are IMHO not Collections, although they are
> collections of objects. They should not be accessible or 
> iterable. They should not need to have collect, or select 
> transformations performed on them.

See, this is root of my problem:  "They should not need to have..."

What happens when they do?  What happens when I have a heap
of tasks and I want to remove all the cancelled tasks?  What
happens when I want to merge two queues into one?  What happens
when I determine that one thread is doing too much work and I
want to split one queue into three?  And so on.  A queue or
queue-like thing (stack, heap) will occassionally require more
than its most common operations (push, peek, pop), in the exact
same way that a Map occassionally requires more than its most
common operations (put, get, remove).  

Saying that a queue should only provide push, peek and pop sounds
to me like saying that a Map should only provide put, get and remove.  
But the Map interface specifies many other operations, many of which
are an absolute pain to implement, and many of which no one ever
implements entirely correctly the first time around (SoftRefHashMap,
StaticBucketMap).

But the utility of the additional Map operations clearly outweighs
the difficulty in implementing them, and furthermore, the common 
operations (put, get, remove) are not affected in terms of 
performance by the existence of, say, entrySet.removeAll(Collection).

I feel the same way about the Collection interface.  I think its
designers made some very good decisions.  I think *any* generic 
container for objects should allow for iteration.  The ability to
inspect a container's contents is too fundamental to too many 
algorithms, patterns and idioms to be abandoned.  

Here's some examples:

1.  As mentioned above, a BinaryHeap of Task objects for some 
kind of Timer implementation.  Users can manually cancel a Task, 
some thread periodically eliminates all cancelled tasks by iterating 
over the BinaryHeap and calling remove().

2.  The Java Virtual Machine begins garbage collection by iterating
over active Thread stacks to find object references.  

3.  All three:  The default toString() method of the buffer's elements
doesn't provide enough information, so for debugging/logging purposes 
you iterate over the elements and print out the extra info you need.

So if nothing else, I'd like Buffers to include an iterator.  But
once they do, the other Collection routines become easy, as all of
them can be implemented in terms of the iterator (this is what 
AbstractCollection does).  

I really believe that having Buffer extend Collection will meet many
more users' needs.

-Paul


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


Mime
View raw message