RFR - JDK-8203442 String::transform (Code Review)
amaembo at gmail.com
Mon Dec 3 11:32:25 UTC 2018
+1 to Stephen and Remi. I personally see no reason to hurry up with
this API: unlike trimming/indenting methods this one doesn't look
crucial for raw string literals. I don't see that this method blocks
> For info, AWS SDK v2 has chosen applyMutation() for a similar concept:
Unfortunately this name serves well only for mutable objects, like
builders. For String it looks confusing.
With best regards,
On Sat, Dec 1, 2018 at 5:27 AM Remi Forax <forax at univ-mlv.fr> wrote:
> I fully agree with Stephen.
> ----- Mail original -----
> > De: "Stephen Colebourne" <scolebourne at joda.org>
> > À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoyé: Vendredi 30 Novembre 2018 12:06:23
> > Objet: Re: RFR - JDK-8203442 String::transform (Code Review)
> > I see from Twitter (!!!) that this has been pushed. This appears to have
> > happened without this thread coming to a clear conclusion, particularly wrt
> > criticism of transform() as a suitable method name in the broader context.
> > I also do not think that the code review was completed correctly and in
> > public, which I find concerning.
> > The two public threads are:
> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056574.html
> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056592.html
> > The last webrev had the name map() and no further webrev was published that
> > I can see. I can see no explicit public approvals of the change from
> > reviewers. And plenty of concern about the method name, especially map()
> > but also transform().
> > While I'm well aware of the danger of public bikeshedding, I also think
> > that adding methods to `String` deserves more care than this has been
> > shown. In my view the change should be reverted, and retargetted to Java 13
> > to allow for a proper conclusion to the discussion.
> > For info, AWS SDK v2 has chosen applyMutation() for a similar concept:
> > https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/utils/builder/SdkBuilder.html#applyMutation-java.util.function.Consumer-
> > Stephen
> > On Wed, 14 Nov 2018, 14:18 Stephen Colebourne <scolebourne at joda.org wrote:
> >> On Tue, 13 Nov 2018 at 15:44, Brian Goetz <brian.goetz at oracle.com> wrote:
> >> > 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.
> >> I'd be more comforted if there was a commitment to add the method to
> >> Stream and Optional in Java 12 or 13.
> >> I also agree with Remi that `transform()` is a poor name for Stream,
> >> and thus it is a poor name for String. I doubt there is a perfect
> >> name, process() or apply() seem like good candidates.
> >> Stephen
More information about the core-libs-dev