Design for collections upgrades

[Sam Pullara]

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

Sam

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