Whither FlatMapper?

[Remi Forax]

On 04/08/2013 10:05 PM, Brian Goetz wrote:
> 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>>)
>

me trying to understand ...
we don't have more forms due to the primitive specialization ?

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

Rémi

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