commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [Commons-Avalon:collections] Buffer integration [was: code integration]
Date Thu, 20 Jun 2002 21:18:31 GMT
Sorry for missing most of the discussion. However, as a fifo, if I was
*using* this class I would not expect to be able to call remove(). Its first
in first out - that is its contract - unsupported operation seems entirely
appropriate. In other words its not about whether it *can* be made to
support remove(), but whether it *should*. This doesn't affect the
usefullness re the CollectionUtils class (as they don't use remove()).

Also, I concur with any name containing Fifo. Both Buffer and Queue are
overloaded in my mind, so I would prefer Fifo on its own.

I support the merging from avalon though ;-)

Stephen

From: "Berin Loritsch" <bloritsch@apache.org>
> > From: Jack, Paul [mailto:pjack@sfaf.org]
> >
> > Okay, thought I'd try to prove my point by actually doing
> > it.  Attached is a version of FixedSizeBuffer that implements
> > Collection.  Also attached is a unit test for
> > FixedSizeBuffer. It extends our TestCollection class which is
> > pretty thorough. Operations are confirmed against an
> > ArrayList to make sure that the Buffer still contains the
> > right elements in the right
> > order, so the odds of something biting us in the butt later
> > are greatly reduced.
> >
> > Note that the add(Object) and remove() methods haven't
> > changed. (Well, okay, see the PS below).
> >
> > It passes all the tests.  See?  Minimal effort, full
> > collections compatibility.  Essentially all I had to do was
> > implement the iterator.  (And I'm pretty sure
> > VariableSizeBuffer can re-use the same iterator, though I'd
> > have to look more closely).
>
>
> You win.  I loose (the argument).  We all win.
>
> Let's get the stuff moved over...
>
> ;P
>
> > Regarding the naming issue, if it'll avoid collisions within
> > Jarkata, I guess I'm okay with Buffer as a name.  But maybe
> > FifoBuffer instead?  Or just Fifo?  Hm.  I'm just looking for
> > something that makes it apparent at a glance what the class is for...
>
> Fifo or FifoBuffer are good names.
>
> I thought Buffer was good enough at the time.
>
>
> >
> > -Paul
> >
> > PS  I made add(Object) return a boolean to be compatible with
> > the Collection interface; also, I used NoSuchElementException
> > and IllegalStateException, but only because it reduced the
> > number of files I had to attach here.  I'm okay with using
> > the Overflow/Underflow exceptions too, I was just trying to
> > make my point quickly...
>
>
> Cool.  The Overflow/Underflow exceptions are more specific to
> the FifoBuffer, so I'd like to keep them--at least in respects
> to add()/remove()
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
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