Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type])

[Neal Gafter]

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.

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

- 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