> De: "Paul Sandoz" <paul.san...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Brian Goetz" <brian.go...@oracle.com>, "Julia Boes" > <julia.b...@oracle.com>, "core-libs-dev" <core-libs-dev@openjdk.java.net>, > "Patrick Concannon" <patrick.concan...@oracle.com> > Envoyé: Jeudi 2 Juillet 2020 19:46:22 > Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more > amenable > to pushing’
> Hi Remi, > This was my suggestion not Brian’s. I proposed to place these interfaces in > the > current location, likely to be renamed in accordance with the operation name, > when that settles. It's my way to summon him given that he was the spec lead on the Stream API. > The rational is that they will fade away in unison with Int/*/Stream when > generic specialization becomes available. The intent is to scope them to the > specific purpose, and perhaps discourage their use outside this scope. Of > course we cannot stop developers using them, but it should be clearer that > it's > not recommended. > IMHO your reasoning for delaying is placing the cart before the horse. This > method has value now, the functional interfaces far less so (and in the future > even less so), and we can reasonably reduce the scope of the API surface, > getting the signature we want on Stream. > This method has value now, the functional interfaces far less I understand the goal but it's not how Java is designed, a publicly visible method that takes a lambda requires the corresponding functional interface to be public. Trying to hide the functional interface just makes the code harder to read/understand, which go against one of the core principle of Java. Also do not forget that once you start to make something different for mapMulti than for the rest of the methods of Stream, it makes automatically the Stream API harder to use/understand because the way to use the API not regular anymore. > Paul. Rémi you can not get your cart without everybody seeing the horse. >> On Jul 2, 2020, at 10:24 AM, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] >> wrote: >> Brian, I understand that adding new functional interfaces has a cost and when >> you know that generics over primitive types are around the corner, it starts >> to >> be an issue, but the compromise to put them in another place hoping that >> people >> will not find them is not very appealing, to say the least. Moreover, i'm >> pretty sure IDEs will find them anyway, so in the end, we are just creating >> another inconsistency. >> The cost of adding a new functional interfaces is perhaps too big compared to >> the need of introducing multiMap (still dislike the name). >> In that case, it's far better to wait and introduce multiMap() later when >> generics over primitives is added to Java. >> Rémi >>> De: "Patrick Concannon" < [ mailto:patrick.concan...@oracle.com | >>> patrick.concan...@oracle.com ] > >>> À: "Remi Forax" < [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] > >>> Cc: "Julia Boes" < [ mailto:julia.b...@oracle.com | julia.b...@oracle.com ] >>> >, >>> "core-libs-dev" >>> < [ mailto:core-libs-dev@openjdk.java.net | core-libs-dev@openjdk.java.net >>> ] > >>> Envoyé: Jeudi 2 Juillet 2020 18:45:13 >>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more >>> amenable >>> to pushing’ >>> 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 < [ [ mailto:fo...@univ-mlv.fr | >>>> mailto:fo...@univ-mlv.fr ] | >>>> [ mailto:fo...@univ-mlv.fr | 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" < [ [ mailto:patrick.concan...@oracle.com | >>>>> mailto:patrick.concan...@oracle.com ] | >>>>> [ mailto:patrick.concan...@oracle.com | patrick.concan...@oracle.com ] ] > >>>>> À: "Julia Boes" < [ [ mailto:julia.b...@oracle.com | >>>>> mailto:julia.b...@oracle.com ] | [ mailto:julia.b...@oracle.com | >>>>> julia.b...@oracle.com ] ] > >>>>> Cc: "core-libs-dev" < [ [ mailto:core-libs-dev@openjdk.java.net | >>>>> mailto:core-libs-dev@openjdk.java.net ] | >>>>> [ mailto:core-libs-dev@openjdk.java.net | 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/ ] ] >>>>> < [ 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 < [ mailto:julia.b...@oracle.com | >>>>>> julia.b...@oracle.com ] > wrote: >>>>>> w
