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 17:41:22 GMT
> On the topic of "designing up-front" or "waiting for the
> need", I tend to prefer the eXtreme Programming style of
> "wait for the need".  But since there is such pressure to
> not change any released API then we're pretty much stuck
> with having to be very thoughtful up-front and living with
> what's been done before.

Or do as little as possible up-front, make it right, and know that you can
always *add* things later.  One way to reduce the chance of being "stuck
with" a bad API design is to minimize the number of things we're designing
in the first place.

Shipping Collections without an IntList interface, and then later adding
IntList at the time we have something other an implementation of
AbstractIntArrayList that would fit that interface doesn't seem problematic
at all to me.  Adding IntList (and anticipating, say, something like
IntLinkedList) is pretty safe gamble, but don't trick yourself into thinking
that's less of a commitment than not having it.

Or more to the point, consider CapacityList. Obviously any CapacityList is
meant to be more or less compatiable with ArrayList.  I might want to, for
example, constrain a method signature to the CapacityList interface because
it uses the List methods as well as trimToSize and ensureCapacity.  But
since doing so means a client can't pass ArrayList to that method, I've
defeated the purpose of creating the CapacityList interface in the first
place--giving me an abstraction of lists that are more or less compatiable
with ArrayList.

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