explode()

[Brian Goetz]

> Hmm. So the methods I proposed, Consumer.accept(Collection) and
> Consumer.accept(Stream), are functionally identical to
> Collection.forEach(consumer) and Stream.forEach(consumer), and thus have
> little benefit except in that various Consumer implementations might be
> able to override them and do something more efficient. Which in turn
> means that these forEach() methods would have to delegate straight to
> them; they become pure conveniences only.

Mostly so, though I could imagine (I realize I'm undermining my earlier 
position) that Sink.acceptAll(Stream) might be able to do something 
better in the case when we explode an element to an infinite stream. 
Currently, exploding an element to an infinite stream:

   ints.explode(i -> Streams.repeat(() -> i)).getFirst()

would never terminate, even though it theoretically could.

Having either the acceptAll() method on Consumer OR the send(Stream) 
method on DownstreamThingie, would leave us a door to eventually fix 
that issue; asking users to do stream.forEach(consumer) would make it 
harder to do so.

My worry is that, especially given the late date, I'd like to minimize 
the number of default methods on SAM types.

> But when considering those use cases, one of them may arise if drop
> Downstream and have explode() use Consumer instead. In that case, does
> it break explode() if we have users just using stream.forEach(consumer)
> and collection.forEach(consumer) instead of downstream.send(stream) and
> downstream.send(collection)?

Another possibility is to return to an intermediate position, where 
there was a SAM for "function from singleton to multi", such as the 
Exploder you suggest.  Once we do that, then putting a renamed 
Downstream in Exploder makes it clearer:

interface Exploder<T,U> {
     void explode(T input, ShrapnelCatcher<U> catcher);

     interface ShrapnelCatcher<U> {
         void accept(U u);
         default void acceptAll(Collection<U> c) { ... }
         ...
     }
}



>
>
> On Thu, Jan 24, 2013 at 2:43 PM, Kevin Bourrillion <kevinb at google.com
> <mailto:kevinb at google.com>> wrote:
>
>     explode() is aptly named for what it did to my brain when I
>     encountered it. :-)
>
>     A few things are adding up to make it impenetrable.
>
>     1. The vast majority of the Stream API, save the obvious exceptions
>     like forEach(), is solidly in the functional style. Collectors
>     aren't really, but as long as I use the prepackaged ones, it
>     /feels/ fairly functional anyway. Now suddenly there's explode,
>     which doesn't feel functional at all. Instead, I need to think of
>     the bit of code I provide to it as an active participant in a
>     pipeline. Things are fed to me, I feed things on down the line. This
>     makes it different, and different is automatically confusing. This
>     can't really be /corrected/, but seems worth nothing; maybe we can
>     account for the difference somehow.
>
>     2. In attempting to learn it, I'm confronted with a type,
>     Stream.Downstream<U>, which I won't have heard of before that
>     moment, and whose name reveals little.  Is there any particular
>     reason that Sink/Consumer, with its accept(T) method, should
>     not also have "default" methods implementing accept(Collection<T>)
>     and accept(Stream<T>) and accept(T[])?  I can't think of any; those
>     sound just plain handy.  And if we added those, would there be
>     enough value in preserving Downstream as an identically-signatured
>     type?  We could dispense with it, as I've done below.
>
>     3. Except sometimes there /is/ value in having a special type even
>     if its signature is identical to another.  I suspect that a custom
>     type could help quite a bit in this case:
>
>         interface Exploder<T,R> {
>            /**
>             * Maps {code input} to zero or more instances of R, sending
>         these
>             * to {@code resultConsumer} to be included in the results of
>             * {@link Stream#explode(Exploder)}.
>             */
>            void explode(T input, Consumer<R> resultConsumer);
>         }
>
>
>     4. Then there is the name "explode". It's... okay. "unpack"? Nah. It
>     seems maybe 40% possible that a great name is out there eluding us....
>
>
>
>     --
>     Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
>     <mailto:kevinb at google.com>
>
>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
> <mailto:kevinb at google.com>