explode()

[Brian Goetz]

The other alternative is more overloading:

   explode(Exploder<T,U>) // current
   explodeToCollection(Function<T,Collection<U>>)
   explodeToStream(Function<T,Stream<U>>)
   explodeToArray(Function<T,U[]>)

Note that many people think "all they want" is the second one, but 
they're wrong.

IF we can only have one, there's no discussion -- it's the first one, 
since one can relatively easily derive the others from the first. 
However, the first does tend to induce head-explosion.



On 1/29/2013 1:14 PM, Brian Goetz wrote:
>> 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>