Whither FlatMapper?

[Brian Goetz]

A slight correction: if we remove the flatMap(FlatMapper), there is no 
fluent form that is as efficient as the removed form that accepts (T, 
Consumer<T>), since there's no other way to get your hands on the 
downstream Sink.  (Not that this dampens my enthusiasm for removing it 
much.)

For the truly diffident, a middle ground does exist: remove FlatMapper 
and its six brothers as a named SAM, and replace it with BiConsumer<T, 
Consumer<T>>, leaving both forms of flatMap methods in place:
   flatMap(Function<T,STream<U>>)
   flapMap(BiConsumer<T, Consumer<U>>)

The main advantage being that the package javadoc is not polluted by 
seven forms of FlatMapper.

On 4/8/2013 3:27 PM, Doug Lea wrote:
> On 04/07/13 19:01, Sam Pullara wrote:
>> I'm a big fan of the current FlatMapper stuff that takes a Consumer.
>> Much more
>> efficient and straightforward when you don't have a stream or
>> collection to just
>> return. Here is some code that uses 3 of them for good effect:
>
> I think the main issue is whether, given the user reactions so far, we
> should insist on people using a generally better but non-obvious
> approach to flat-mapping. Considering that anyone *could* write their own
> FlatMappers layered on top of existing functionality (we could
> even show how to do it as a code example somewhere), I'm with
> Brian on this: give people the obvious forms in the API. People
> who are most likely to use it are the least likely to be obsessive
> about its performance. And when they are, they can learn about
> alternatives.
>
> -Doug
>