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

[Howard Lovatt]

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

 -- Howard.

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



-- 
  -- Howard.