Hiding is a misleading characterization. It’s about reducing the API surface of this feature for reasons previously mentioned. I am reluctant to impose ObjIntConsumer vs. IntObjConsumer on developers.
Paul. > On Jul 2, 2020, at 12:36 PM, fo...@univ-mlv.fr wrote: > > > 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, 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" <patrick.concan...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Julia Boes" <julia.b...@oracle.com>, "core-libs-dev" > <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/ ] > > 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| > 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| > patrick.concan...@oracle.com] > > À: "Julia Boes" < [mailto:julia.b...@oracle.com|julia.b...@oracle.com] > > Cc: "core-libs-dev" < [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/> > > Kind regards, > > Patrick > > On 26 Jun 2020, at 17:46, Julia Boes <julia.b...@oracle.com> wrote: > > w
