commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [Commons-Avalon:collections] code integration
Date Thu, 20 Jun 2002 17:55:06 GMT
> From: Jack, Paul [mailto:pjack@sfaf.org] 
> 
> > I thought you did:
> > 
> > On Thu, 20 Jun 2002, Jack, Paul wrote:
> > > 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.
> 
> Heh, poor word choice.  The elements would have to be shifted 
> but there wouldn't be any new memory allocations or 
> System.arraycopy involved.


A lot of shifting involved.

  What if the end index is before the begin index?  It is a
circular buffer, so that is within normal operating conditions.

Imagine this scenario:

   3|4|5|N|N|1|2
       E     B

Remove (2).

Hmm.

Ok, I have to copy buf[0] to buf[6],
then I have to copy buf[1-2] to buf[0-1],
then I have to move the E marker.

The index operations are a place where error can creep in and
bite you in the butt.  It took a few bug fixes to get them to
operate correctly.


> > And I don't see why the *optional* operations *need* to be 
> supported.
> 
> Well, the effort to support them is minimal; and it'd be a 
> bit wierd to have a collection that does support element removal but 
> raises UnsupportedOperation on the standard removal methods.

It seems normal to the Java spec writers.  Check the docs out
on Collections/Iterator.  It's not uncommon--Esp. with the
Collections.unmodifiable****().


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