Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type])
howard.lovatt at gmail.com
Tue Mar 8 14:27:32 PST 2011
+1 for Neal's suggestions, I have also found:
to( T result ) and to( Collection<T> result ) to be useful, i.e.
much like toArray( T result ) in List.
PS I think someone else has previously suggested the to() methods with
lazy evaluation as the best interface (unfortunately I can't remember
who that was and therefore can't give credit where credit is due).
On 9 March 2011 08:16, Neal Gafter <neal at gafter.com> 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.
> 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
> - 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