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] code integration
Date Thu, 20 Jun 2002 17:10:43 GMT
> 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.

 
> In fact the Buffer takes advantage of that fact.  The main
> issue is with the Iterator.remove(), and the fact that the
> elements as they come off the buffer should be removed.
> 
> The Iterator is particularly problematic.  Do you remove the
> items from the buffer after they have been read by the Iterator?

Iterator.remove() would have to completely recopy the 
internal array and reset the head and tail.  Again, it'd
be extremely slow -- but wouldn't affect the add() and remove()
implementations.

And the resulting classes would be more interoperable.

-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