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.lev...@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 <fo...@univ-mlv.fr> >>>> <mailto:fo...@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.concan...@oracle.com> >>>>> <mailto:patrick.concan...@oracle.com> >>>>> À: "Julia Boes" <julia.b...@oracle.com> <mailto:julia.b...@oracle.com> >>>>> Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net> >>>>> <mailto:core-libs-dev@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.b...@oracle.com> >>>>>> <mailto:julia.b...@oracle.com> wrote: >>>>>> >>>>>> w
