Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 43806 invoked from network); 20 Aug 2002 17:42:30 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 20 Aug 2002 17:42:30 -0000 Received: (qmail 5505 invoked by uid 97); 20 Aug 2002 17:42:58 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 5489 invoked by uid 97); 20 Aug 2002 17:42:57 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 5477 invoked by uid 98); 20 Aug 2002 17:42:57 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <647FD92C5AF28B488FDF8132535A25F03EB35E@chiex02.britannica.net> From: "Waldhoff, Rodney" To: 'Jakarta Commons Developers List ' Subject: RE: [Collections] primitive pkg - was "Release potential?" Date: Tue, 20 Aug 2002 12:41:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) List-Subscribe: Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24870.CC6B8250" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C24870.CC6B8250 Content-Type: text/plain; charset="iso-8859-1" > 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. ------_=_NextPart_001_01C24870.CC6B8250--