Design for collections upgrades

[Colin Decker]

If there isn't an eager API, the streaming API won't look eager. I can
appreciate not wanting to confuse people who expect filter() to be eager
because they're used to copying filtered values into a new collection,
but that's often not the best thing to do, as has already been pointed out.
Users have been doing that for everything because there hasn't been any
other way provided.

I think that filter, map, etc. should be extension methods on Iterable.
Barring that, the Stream interface or whatever it's called should be
Iterable. Users can't confuse the results of map and filter with eager
Collection copies if those results aren't of the right type.

As I see it, all you gain from an eager API is the ability to create a new
Collection (of a type you have no control over) without calling a copy
method, plus the ability to shoot yourself in the foot over and over with
unnecessary chaining of eager calls.

-- 
Colin


On Tue, Mar 8, 2011 at 4:44 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

>  > I don't feel strongly that we must have an eager
> > API, but I do feel like we can't have a streaming API that looks like
> > an eager one.
>
> I would agree with this position.  There are pluses and minuses for the
> eager version, but we can't make the default API either lazy or parallel
> - you have to ask for that, and it should be reflected in the (static)
> type system.
>
>