Design for collections upgrades

[Rémi Forax]

On 03/08/2011 10:10 PM, Brian Goetz wrote:
>> This would be my preference. Make everything that doesn't need to actually
>> iterate lazy by default and do copying at the end if necessary.
> We're reluctant to do that, because nothing else in Collections is lazy
> by default.  This is one of the biggest gotchas of LinQ in .NET; the
> queries are lazy, but they sure look eager to the untrained eye, and
> this produces surprising results.  We believe that a big difference like
> eager/lazy should be reflected in the type system, such as by returning
> an abstraction like Stream.  Having some collections be lazy and some be
> eager is asking for trouble...

Streams are lazy, Collection are eager.
I think it's not incompatible with what Sam says.

In things.filter(#Thing.isFoo).to(new HashSet<>),
things.filter(#Thing.isFoo) will return a stream and to(new HashSet<>) will
go back to the collection realm.

> Further, I think the choice of eager/lazy is a reasonable one to give
> the programmer.  Programmers who do not need the features offered by
> laziness shouldn't need to learn how laziness works just to use the new
> collection operations.

I don't see the need of having a eager filter().

Rémi