Loose-ends wrapup

[Jim Mayer]

OK... that was a silly request.  A Collector can't bridge to a reader
because it has to consume all of its input.

I liked the idea of a bridge from Stream to Reader, so I downloaded JDK8
b89 and wrote a "StreamReader" class that acts like a StringJoiner and uses
Stream.iterate to generate a sequence of values.  The constructor looks
like:

    StreamReader(Stream<? extends CharSequence> stream, String prefix,
String separator, String suffix)

It works nicely, but the usage is just a bit awkward because it breaks from
the fluid API that stream uses.  For example, a line from my test program
looks like:

    BufferedReader reader = new BufferedReader(new
StreamReader(Arrays.stream(args), "<", ", ", ">"))

This made me wonder if there was a reasonable way to fluidly bridge from a
stream to another data type without fully consuming the stream.  I didn't
find anything like that in the existing API, but I think that it would be
very easy to add.

For example, consider an "applyTo" method on Stream:

    <R> R applyTo(Function<Stream<T>,R> function);

It could even have a default implementation:

        default <R> R applyTo(Function<Stream<T>,R> function) {
            return function.apply(this);
        }

Given an "applyTo" method on Stream, the example that I gave above could be
written:

    BufferedReader reader = Arrays.stream(args).applyTo(s -> new
BufferedReader(new StreamReader(s, "<", ", ", ">")));

To me, this reads a lot like "collect", but allows the use of lazy data
structures that do not fully consume the stream.

Other names I thought of were "applyStreamTo", "passTo", "chainTo", or even
just "to" (by analogy to "toString", etc.), which could yield a form like:


-- Jim


On Fri, May 10, 2013 at 11:58 PM, Jim Mayer <jim at pentastich.org> wrote:

> How about a Collectors method that bridges to a Reader?  I'm thinking of
> something that worked like a combination of toStringJoiner or to
> toStringBuilder and StringStream but that didn't require buffering the
> entire output.
>
> A more general bridge to Reader/Writer and IOStream would also be cool,
> though one would have to think through how to handle IOException (I'd just
> wrap them in a RuntimeException).  That couldn't happen in the case above,
> though.
>
> Jim
> On May 9, 2013 3:15 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>
>> The majority of the lambda libraries code has been put back to the jdk8
>> repositories.  I'm gathering a list of loose ends that we might want to
>> circle back to.  The bar for nontrivial new features at this point is high,
>> but there are plenty of things in the "small tweaks" category that we can
>> do.
>>
>> There's also lots of work remaining in improving the implementation and
>> especially the documentation and specification.  This is a really great
>> time to contribute improvements in this area.
>>
>> Streams -- lingering feature ideas
>>
>>  - Additional tweaking on range generators (see Paul's emails)
>>  - Convenience ints() and longs() generator methods?  (ditto)
>>  - Collector for frequency counting?
>>  - Support for state-based cancelation (e.g., cancelWhen(BooleanSupplier))
>>  - Support for content-based limiting (takeWhile, skipUntil)
>>  - Convenience methods like toList() on Stream
>>
>> SAMs
>>  - Additional static or default methods on standard SAMs?
>>
>> Point lambdafications
>>  - Gotta be more of these?
>>
>> Helper classes
>>  - (I hesitate to even suggest): Optional.{filter,map,flatMap}
>>    Now that Stream.flatMap is settled, it becomes reasonable to consider
>> these.
>>
>> What others have I missed?
>>
>>
>>
>>