commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scolebou...@btopenworld.com
Subject RE: [collections] Primitive collections
Date Tue, 15 Oct 2002 10:33:26 GMT
[change of plan proposed...]

Thanks for the input Rodney. It sounds like you are convinced that new Interfaces and wrappers
are the way to go. And you seem to be offering to code them :-)

However, I believe that were I to accept them into this release as a rushed quick code, with
little review, then this would cause more problems than releasing the current code.

So, as release manager I have to either-
1) delay for this to be completed
2) remove primitives from this release
3) release as is

I really cannot choose option 1 (release is required, and rushed coding/little review is bad).

Option 3 ties our hands for the future.

Rodney, you are the main instigator of this subpackage. If you are willing to code this, then
I feel option 2 makes the most sense. We can code and review with less time pressure, and
maybe get a 2.2 release out soon (its too long between releases anyway).

Any objections to the remove primitives from the release plan?

Stephen

>  from:    "Waldhoff, Rodney" <rwaldhof@us.britannica.com>
> > I suspect there's a design that would allow consistent names to be
> > used (add(), get()), but also to be able to treat something as a
> > real Collection or Map. Something Proxy-ish or Adapter-ish
> > comes to mind; at least, some form of composition.
> 
> Sounds reasonable.
> 
> > (actually, if you're using addInt() it's not
> > clear to me how you could use the class as a real Collection or Map
> > anyway, since you can't use the substitution principle because
> > you've extended the interface). 
> 
> The substitution is meant to go the other way--classes or methods that expect Collection
or Map (or in the only concrete case here, List), can use the primitive version directly.
 I can take an IntArrayList and pass it off to Collections.binarySearch or Collections.shuffle
for example.
> 
> A wrapping (Adapter) approach, something like: 
>  Collections.shuffle(new ListToPrimitiveListAdapter(mylist));
> is a viable alternative, in fact IMO that's preferable.
> 
> Wouldn't be difficult to implement right now if we're willing postpone the collections
release by a day or two.


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