Design for collections upgrades

Sam Pullara sam at
Tue Mar 8 15:25:32 PST 2011

Isn't the eager version really copy(Predicate) rather than filter() that defaults to the concrete type of its source type?


On Mar 8, 2011, at 2:55 PM, Colin Decker wrote:

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

More information about the lambda-dev mailing list