commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruce Eckel" <>
Subject RE: [collections] Primitive collections
Date Tue, 15 Oct 2002 15:27:39 GMT
Option two fits with XP philosophy. Trim features to make the
release, rather than putting something in that doesn't measure up,
or blowing the schedule.

I'm finding this an interesting problem so I would be glad to
interact re design questions. Also, I think Bill Venners would be
interested in this one as well.

*********** REPLY SEPARATOR  ***********

On 10/15/2002 at 11:33 AM wrote:

>[change of plan proposed...]
>Thanks for the input Rodney. It sounds like you are convinced that
>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
>rushed quick code, with little review, then this would cause more
>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
>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?
>>  from:    "Waldhoff, Rodney" <>
>> > 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
>> > 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
>> 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.

Most current information can be found at:
Bruce Eckel
Contains free electronic books: "Thinking in Java 2e" & "Thinking
in C++ 2e"
Please subscribe to my free newsletter -- just send any email to:
My schedule can be found at:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message