Design for collections upgrades
forax at univ-mlv.fr
Tue Mar 8 13:34:19 PST 2011
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
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).
More information about the lambda-dev