RFR - JDK-8203442 String::transform (Code Review)

[Anthony Vanelverdinghe]

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 at openjdk.java.net> on behalf of Remi Forax <forax at 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 at oracle.com>
> À: "Peter Levart" <peter.levart at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at 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