commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [Commons-Avalon:collections] code integration
Date Thu, 20 Jun 2002 17:26:09 GMT
> From: Jack, Paul [] 
> > Essentially that is what it is doing.  I do differentiate 
> between that 
> > and a full fledged Queue as I have that defined in my Event 
> package.  
> > The core Event package does not depend on anything that 
> isn't already 
> > set to be donated to Commons.
> Would you have a problem with the commons.collection.Buffer 
> being renamed to Queue (or possibly FifoQueue?)
> > No!  Buffer should not extend Collection.  You should not 
> be able to 
> > add or remove items from the middle of a Buffer.  It is precisely 
> > that.  A buffer.
> Why shouldn't you?  I mean, sure, the operation will be slow, 
> but no slower than LinkedList.remove(Object).  The existing add() 
> and remove() implementations wouldn't change, and still be 
> lightning fast.  BUT, you'd be able to use the Buffer 
> implementations in a much wider range of contexts.

The remove(Object), remove(Collection), and retain(Object)
methods are optional to implement.  I *highly* recommend not
implementing them.

The added complexity and memory requirements required for
array copying don't outweigh the benefit of using a Buffer/Queue
they way it was designed to be used.

A Fifo is just that.  First in, First out.  There are many
ways where that is very useful.  If you have to remove a particular
item then I suggest using a List.  It's a question of using a
class/interface the way it was designed to be used.

Having looked at the JavaDocs for both Collection and Iterator,
I believe that the Buffer/Queue should choose not to allow the
optional remove() methods.  As per the contract, they would
throw an OpperationUnsupportedException by design.

Their support causes more issues than they solve.

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

View raw message