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

Peter Levart peter.levart at gmail.com
Sun Jul 5 08:21:48 UTC 2020


...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/>
>>
>> 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> 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>
>>>> À: "Julia Boes" <julia.boes at oracle.com>
>>>> Cc: "core-libs-dev" <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/>
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Patrick
>>>>
>>>>> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com> wrote:
>>>>>
>>>>> w


More information about the core-libs-dev mailing list