Design for collections upgrades

[Rémi Forax]

On 03/08/2011 10:16 PM, Neal Gafter wrote:
> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz<brian.goetz at oracle.com>  wrote:
>
>> 1.  Serial / Eager.  This is the straight
>> collections-with-functional-style mode, and some samples have already
>> been checked in as proof of concept.  Operations on collections yield
>> new collections, and you can chain the calls.  It values ease of use
>> over performance (no new concepts like laziness), but the performance
>> model is still highly predictable.
>
> This form has problems: (1) there is no clear choice on the type of
> collection one should build as a result, and (2) it isn't clear this pays
> for itself in usefulness to client, and (3) it can be extremely inefficient
> in some contexts.  Better to have the client use the Serial/Lazy APIs, and
> .toList(), .toSet(), or .toArray(), etc on the final result.  In other
> words, I believe it makes sense for all of these operations to be "lazy",
> and only toList, toSet, toArray and their ilk would be eager.

Not all operations are lazy.
Reduce is not lazy.

> 2.  Serial / Lazy.  Here, the primary abstraction is Stream (name to be
>> chosen later, Remi used "lazy" in his example.)
>
> The JDK already has two such streaming interfaces: Iterable<T>  and
> Collection<T>.

Not sure we can reuse them, I have to think about that.

> - Switching between execution models is mostly a matter of adding an
>> explicit conversion or two in the call chain, as the models are similar
>> enough that the rest of the code should still work (and even mean the
>> same thing.)
>>
> The semantics of the lazy and eager versions of these APIs are different
> enough, semantically, that I don't think they should even be named the
> same.  (My preference is to do away with the eager bulk operations).
>
> Cheers,
> Neal
>

Rémi