Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

[Patrick Concannon]

Hi Peter,

Thanks for your feedback, and for pointing out these mistakes.

I’ve rectified this now, and you can find the latest changes in the new webrev and specdiff below.

webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.04/
specdiff: http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.01/


Kind regards,
Patrick

> On 5 Jul 2020, at 09:21, Peter Levart <peter.levart at gmail.com> wrote:
> 
> ...also note that examples in the Stream javadoc comments, like for example:
> 
> 
> 
>  385      * <pre>{@code
>  386      *     numbers.mapMulti((Consumer<Integer> c, Number n) -> {
>  387      *         if (n instanceof Integer)
>  388      *             c.accept((Integer) n);
>  389      *     });
>  390      * }</pre>
> 
> 
> 
> ...have the arguments (Consumer, element) still wrong. They are swapped now as of latest webrev.03:
> 
> 
> 
>  422     default <R> Stream<R> mapMulti(BiConsumer<? super T, ? super Consumer<R>> mapper) {
> 
> 
> Regards, Peter
> 
> 
> 
> On 7/5/20 10:00 AM, Peter Levart wrote:
>> Hi Patrick, 
>> 
>> 
>> In the test(s), you often use sink::accept: 
>> 
>> 
>>         exerciseOps(data, s -> s.mapMulti((e, sink) -> IntStream.range(0, e).forEach(sink::accept))); 
>> 
>> 
>> ...where you could simply pass just sink: 
>> 
>> 
>>         exerciseOps(data, s -> s.mapMulti((e, sink) -> IntStream.range(0, e).forEach(sink))); 
>> 
>> 
>> Is this intentional and why? 
>> 
>> 
>> Regards, Peter 
>> 
>> 
>> On 7/2/20 6:45 PM, Patrick Concannon wrote: 
>>> Hi Remi, 
>>> 
>>> Well spotted on the bad link. I’ve updated that now. 
>>> 
>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/>
>>> 
>>> As for the placement of the new FIs, it was decided that once we can use primitive types in generics the need for these interfaces will hopefully fade, and it was deemed better to keep them closer together for this reason. This approach also has the benefit of reducing the exposure / footprint of the general functional interfaces. 
>>> 
>>> Kind regards, 
>>> 
>>> Patrick 
>>> 
>>> 
>>>> On 2 Jul 2020, at 15:30, Remi Forax <forax at univ-mlv.fr> <mailto:forax at univ-mlv.fr> wrote: 
>>>> 
>>>> Hi Patrick & Julia, 
>>>> this version starts to look good. 
>>>> 
>>>> I just don't understand why the new functional interfaces are not in java.util.function like the other ones ? 
>>>> (BTW, in the javadoc, the link to the summary overview point to the wrong one, to java.util.stream and not java.util.function). 
>>>> 
>>>> About the examples, i will try to think about that this evening :) 
>>>> 
>>>> regards, 
>>>> Rémi 
>>>> 
>>>> ----- Mail original ----- 
>>>>> De: "Patrick Concannon" <patrick.concannon at oracle.com> <mailto:patrick.concannon at oracle.com> 
>>>>> À: "Julia Boes" <julia.boes at oracle.com> <mailto:julia.boes at oracle.com> 
>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> <mailto:core-libs-dev at openjdk.java.net> 
>>>>> Envoyé: Jeudi 2 Juillet 2020 15:30:45 
>>>>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’ 
>>>>> Hi, 
>>>>> 
>>>>> John: Thanks for your feedback. We've rearranged the ordering of the parameters 
>>>>> of the BiConsumer to follow the convention you suggested, and hopefully improve 
>>>>> readability going forward. Additional FIs (IntObjConsumer, etc.) have been 
>>>>> added as sub-interfaces to the corresponding Stream classes i.e. {Int, Double, 
>>>>> Long}Stream. 
>>>>> 
>>>>> Remi: Your argument makes sense, and we have updated the BiConsumers generic 
>>>>> type to `<? super Consumer<R>>` as you suggested. Thanks for pointing this out. 
>>>>> We have also removed the caching. 
>>>>> WRT to the wrappers used in the examples: good examples are tough to nail down. 
>>>>> We think the examples in their current form do a good job of demonstrating how 
>>>>> the method can be used, but we welcome any alternative suggestions. 
>>>>> 
>>>>> 
>>>>> The changes discussed can be found in the updated webrev below. 
>>>>> 
>>>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/> 
>>>>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/> 
>>>>> 
>>>>> 
>>>>> Kind regards, 
>>>>> 
>>>>> Patrick 
>>>>> 
>>>>>> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com> <mailto:julia.boes at oracle.com> wrote: 
>>>>>> 
>>>>>> w