Hi Remi, Brian,
What about ‘asInputTo’ or some variant thereof (e.g. using Argument or the abbreviated Arg instead of Input; or dropping/replacing either of the prefix/suffix)? This would give, for example: `raw html`.asInputTo(HtmlDocument::new) source.stream().asInputTo(this::maybeAddFilter) To me, this name clearly relates the object with its argument: the object serves ‘as input to’ the argument (plus it hints at the fact that the argument is a Function). And since it’s just using general terminology, it’s applicable in a broad context, yet is unlikely to clash or look awkward anywhere. Kind regards, Anthony ________________________________ From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Remi Forax <fo...@univ-mlv.fr> Sent: Wednesday, November 14, 2018 12:36:16 PM To: Brian Goetz Cc: core-libs-dev Subject: Re: RFR - JDK-8203442 String::transform (Code Review) Hi Brian, ----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Peter Levart" <peter.lev...@gmail.com> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Mardi 13 Novembre 2018 15:37:31 > Objet: Re: RFR - JDK-8203442 String::transform (Code Review) >> An argument against re-using the name map() for this String method is that >> Stream.map() and Optional.map() act on the element(s) of the "container" the >> method is invoked upon, and return the same raw part of type with type >> parameter adjusted, while String.map() would be passing the target object >> itself to the function and returning an arbitrary type. > > This is exactly why we did not choose the name map() when this feature was > proposed. (Such is life when a platform is accrete-only; you have to live > with > your past decisions, good and bad.) > > (I didn’t see the proposal to rename transform() to map() fly by; I would have > made the same comments as Peter.) as i said earlier, we have https://bugs.openjdk.java.net/browse/JDK-8140283 that asks for the same kind of method on Stream, i think it's a good idea to have some kind or coordination here. While 'transform' is a ok name for String, it's a bad name for Stream. All intermediary ops are transformations, but 'transform' doesn't subsume them. A method named transform will act as a magnet for Stream newbies that want to do transformation on a stream. Perhaps 'chain' as proposed in JDK-8140283 is a better name ? > >> Other languages have introduced an operator to solve that issue (function >> call >> syntax is not fluent) like by example the operator '|>' as in "foo" |> >> Utils.capitalizeFirstLetter. > > Yes, we know :) But we don’t have any current plans to do that, nor use-site > extension methods, nor does it seem likely to come to the top of the language > priority list very soon. So its not a choice between |> and .transform(); > it’s > a choice between transform() and nothing. Picking transform() seems pretty > good here. > > Stephen raised the issue of a “broader context”; indeed, the intention of > adding > a transform() method here was that it would be feasible to add to other types > for which it was suitable. String is an obvious candidate for “do it first”, > but this is within a broader context. ok about the rationale, we just need to find a good name. Rémi