Whither FlatMapper?

[Sam Pullara]

That seems reasonable to me.

Sam

On Apr 8, 2013, at 4:02 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Actually, there is an allocation-free path to get almost the Consumer-version performance with the non-consumer version, using the proposed StreamBuilder type (that also implements Spliterator and Stream, so "building" is allocation-free), and stuffing that into a ThreadLocal:
> 
>  ThreadLocal<StreamBuilder> tl = ...
> 
>  ...
> 
>  stream.flatMap(e -> {
>      StreamBuilder sb = tl.get();
>      sb.init();
>      // stuff elements into sb
>      return sb.build();  // basically a no-op
>  });
> 
> So I recant my earlier statement that there's no efficient way to simulate the consumer form.  Its just ugly.
> 
> And the above can be captured by a wrapping helper:
> 
>  Function<T, Stream<U>> = wrapWithThreadLocalStreamBuilder(
>     (T t, Consumer<U> target) -> { /* old way */ });
> 
> So, I'm even more firmly in the "remove it" camp.
> 
> On 4/8/2013 4: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>>)
>> 
>> 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
>>>