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-bounces@openjdk.java.net> on behalf of Remi Forax <forax@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.goetz@oracle.com> À: "Peter Levart" <peter.levart@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