commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <pj...@sfaf.org>
Subject RE: [Collections] primitive pkg - was "Release potential?"
Date Tue, 20 Aug 2002 21:18:00 GMT
<snip all the use cases, good info to have finally, thanks>

> Can I imagine a circumstance when I might want to have the forwarding
> methods distinct from the capacity methods? Sure. Can I imagine a
> circumstance where I might want a list of ints that's not 
> storing them in an array?  Sure.  That's why I haven't made any 
> design decisions that preclude any of that.  But I also haven't 
> had a *need* for any of this yet, so why go around building things 
> I don't yet need?  

Because you're not the only consumer of collections, that's why. 
The API is currently filled with all sorts of wonderful "Wow, this
works right now" things that either (a) don't work or (b) can't
be usefully extended.

We have user feedback (Jonathan) indicating that he wants to be 
able to implement his own primitive lists.  This is a reasonable
request for a generic utility API.

Based on that feedback, it seemed to make sense to eliminate the
capacity() et al methods OR to place them in their own interface,
to minimize the number of classes in the package.

But now that I finally know how you're using the classes and why,
(and also now that I have a better understanding of the code),
it would seem that we need both layers of abstraction.

Which I'm going to implement unless you -1: 

(a)  Keep Abstract*List, with forwarding methods.
(b)  Move capacity() et all to Abstract*ArrayList
(c)  Superclass of concrete classes is Abstract*ArrayList.
(d)  No interfaces yet.

-Paul





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