Whither FlatMapper?

[Sam Pullara]

I like this plan. I'd hate to lose the lower level API.

Sam

On Apr 8, 2013, at 1:05 PM, Brian Goetz <brian.goetz at oracle.com> 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>>)
> 
> 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
>>