explode() (original) (raw)

Kevin Bourrillion kevinb at google.com
Thu Jan 24 14:43:45 PST 2013

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.

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.
In attempting to learn it, I'm confronted with a type, Stream.Downstream, 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) and accept(Stream) 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.
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 resultConsumer); }

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