RE: [Commons-Avalon:collections] Buffer integration [was: code in tegration]

["Jack, Paul" <pj...@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).

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

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

Re: [Commons-Avalon:collections] Buffer integration [was: code integration]

[Stephen Colebourne <sc...@btopenworld.com>]

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" <bl...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [Commons-Avalon:collections] Buffer integration [was: code integration]

[Berin Loritsch <bl...@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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>