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

[Jim Mayer]

I am a huge fan of lazy evaluation.

I think I like the "to( Collection<T> result )" syntax that Howard mentions,
but I'm concerned about the fact that, in general, the size of the result
can't be known in advance.  Methods like "toList" might be able to chose
implementations that are especially efficient for interfacing with the
stream implementation.

Some questions:

   1. Would the stream types implement Iterable?  If the did, then one could
   write "for (Fu x : something.asStream().map(#{...})) {...}", which would be
   a nice bridge to the existing language and which would avoid instantiating
   an unnecessary intermediate collection.
   2. Are you anticipating an explicit API for creating the stream types
   outside of the collections classes?
   3. With lazy evaluation, one can cleanly represent infinite series.
    Would we we enable this?
   4. Would "Iterator" get an "asStream" method?  I suppose that would cover
   (2) and (3).
   5. What about operations on streams (e.g., concatenation, interleaving,
   selection (i.e., use values in one stream to select values from another)?
   6. Is there anything clever that can be done when generating arrays,
   ArrayLists, etc. from a stream?  When filters are used the size of the
   result won't be known until the entire stream is processed, but in some
   cases one might be able to know the final size (or, in other cases, an upper
   bound).
   7. Have you considered adding constructors to the collection classes that
   take streams (e.g., new ArrayList<T>(Stream<T>))?

I'd better stop :-)

This reminds me of Richard Water's SERIES package for common list (
http://series.sourceforge.net/).  It's been a while, but I really enjoyed
using it.

-- Jim

On Tue, Mar 8, 2011 at 5:27 PM, Howard Lovatt <howard.lovatt at gmail.com>wrote:

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