Loose-ends wrapup

[Jim Mayer]

Sorry... didn't mean to send that quite yet.  I'll just stop :-)

Jim


On Sun, May 12, 2013 at 12:26 AM, Jim Mayer <jim at pentastich.org> wrote:

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