commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [Commons-Avalon:collections] Buffer integration [was: code integration]
Date Tue, 25 Jun 2002 19:00:05 GMT
>From Joshua Bloch's Effective Java book.
Item 14, favour composition over inheritance
"If you are tempted to have a class B extend a class A, ask yourself the
question 'is every B really an A?' If you cannot truthfully answer yes to
this question, B should not extend A......There are a number of obvious
violations of this principle in the Java platform libraries. For example, a
stack is not a Vector, so Stack should not extend Vector. Similarly, a
property list is not a hash table so Properties should not extend Hashtable.
In both cases, composition would have been appropriate."

I think we should at least be considering why the person who lead the design
of the collections API doesn't think that a Stack is a List. I accept that
this text doesn't rule out Collection, but I think it was implied.

There may be a case to add clear() to the Buffer interface, but I kind of
think that the items were put onto the queue for a reason.

One more thing, this is nothing to do with difficulty of implementation. I
care about the interface, not the implementor.

However, I seem to be in a minority of one here and I don't see any
compromise on the horizon. I'm not intending to block it, so I suggest
proceeding with Buffer extending Collection  :-(


From: "Jack, Paul" <>
> > 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message