commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldhoff, Rodney" <>
Subject RE: [Collections] primitive pkg - was "Release potential?"
Date Tue, 20 Aug 2002 12:27:58 GMT
> I'd much rather see something in the main package like
>  public interface CapacityList extends List {
>      int capacity();
>      void ensureCapacity(int);
>      void trimToSize();
>  }
> Then not only would all the current concrete primitive list 
> implementations also implement that interface, but also 
> FastArrayList and ArrayStack in the main package.
Of course, the one CapacityList that really matters--java.util.ArrayList, is
never going to implement that interface, which limits the utility, but I'm
not opposed to the idea.

I still want something that plays the role of AbstractIntArrayList right
now--something that implements both IntList and CapacityList, because that's
the common interface of IntArrayList and UnsignedShortArrayList and I want
to be able to use IntArrayList and UnsignedShortArrayList interchangably. 

So this means:

* add the CapacityList interface 
* add the XxxList interfaces (where Xxx = Int, Short, Float, etc.)
* change AbstractXxxArrayList to AbstractXxxList extends XxxList, and remove
the capacity methods
* add the XxxCapacityList interfaces, extending CapacityList and XxxList
* have XxxArrayList and UnsignedYyyyArrayList extend AbstractXxxList and
implementing XxxCapacityList

Leaving us with:





   AbstractFloatList implements FloatList
   AbstractIntList implements IntList
   AbstractLongList implements LongList
   AbstractShortList implements ShortList

   [CapacityFloatList extends FloatList, CapacityList]
   CapacityIntList extends IntList, CapacityList
   CapacityLongList extends LongList, CapacityList
   CapacityShortList extends ShortList, CapacityList

   FloatArrayList extends AbstractFloatList implements CapacityFloatList

   UnsignedByteArrayList extends AbstractShortList implements
   ShortArrayList extends AbstractShortList implements CapacityShortList
   IntArrayList extends AbstractIntList implements CapacityIntList
   UnsignedShortArrayList extends AbstractIntList implements CapacityIntList
   LongArrayList extends AbstractLongList implements CapacityLongList
   UnsignedIntArrayList extends AbstractLongList implements CapacityLongList

I think I'm OK with that, though it seems like a lot of abstractions for
rather few implementations.  I do think it's a technically correct
deconstruction of the domain.

Ideally we could now look at that list and figure out the parts we don't
really need right now, and just make sure that our implementation of the
parts we do need don't preclude this overall design, rather than creating
four layers of abstraction where we currently have at most two

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message