commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections] Primitive collections
Date Tue, 15 Oct 2002 21:29:21 GMT
The exclusion plan seems to be OK.

For the primitive design, my first approach would be to start with
IntCollection and IntList interfaces and work out. I think that the
interfaces can be exactly the same as the Collection and List interfaces,
but returning/taking in ints instead of Objects. Just to achieve this will
also require an IntIterator.

The current implementations also have a 'capacity' concept, and that will
need to be considered too. Maybe a separate interface.

Once we have Int working, other primitive types are just search and replace.
Then we will need a PrimitiveUtils static class to contain the adaptors.

Well, its a starting point.....

Stephen

----- Original Message -----
From: "Bruce Eckel" <Bruce@EckelObjects.com>
> 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 scolebourne@btopenworld.com wrote:
>
> >[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.
>
>
>
> Most current information can be found at:
> http://www.mindview.net/Etc/notes.html
> ===================
> Bruce Eckel    http://www.BruceEckel.com
> Contains free electronic books: "Thinking in Java 2e" & "Thinking
> in C++ 2e"
> Please subscribe to my free newsletter -- just send any email to:
> join-eckel-oo-programming@earth.lyris.net
> My schedule can be found at:
> http://www.mindview.net/Calendar
> ===================
>
>


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