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

Jim Laskey james.laskey at oracle.com
Mon Nov 12 14:04:42 UTC 2018

updated webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev-02/index.html <http://cr.openjdk.java.net/~jlaskey/8203442/webrev-02/index.html>

> On Sep 21, 2018, at 7:42 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> ----- Mail original -----
>> De: "Alan Bateman" <Alan.Bateman at oracle.com>
>> À: "Jim Laskey" <james.laskey at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoyé: Vendredi 21 Septembre 2018 12:22:42
>> Objet: Re: RFR - JDK-8203442 String::transform (Code Review)
>> On 18/09/2018 18:52, Jim Laskey wrote:
>>> Please review the code for String::transform. The goal is to provide a String
>>> instance method to allow function application of custom transformations applied
>>> to an instance of String.
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev/index.html
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8203442
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8203703
>> I hate to bring up naming but if I have a Stream<String> or
>> Optional<String> then I'll use the "map" method to apply the mapping
>> function. Has this already been through the naming bike shed and it
>> settled on "transform"? Maybe a different name was chosen after looking
>> at code that would use it in stream operations? Maybe "transform" was
>> used as the argument to the function is always text? I'm not interested
>> in re-opening any discussions, just trying to see if options are
>> captured in a mail somewhere.
>> I'm also wondering if this is general enough to be defined by
>> CharSequence. Retrofitting CharSequence is always problematic and never
>> done lightly but I'm just wondering if it has been discussed and
>> dismissed. I don't think it could be done at a later time, at least not
>> without changing the input type parameter so that the mapping function
>> is Function<? super CharSequence, R> rather than Function<String, R>.
> the main issue is that a lot of utility methods take a String as parameter, not a CharSequence :(
> and Function<? super String, R> is a supertype not a subtype of Function<? super CharSequence, R>.
>> -Alan
> Rémi

More information about the core-libs-dev mailing list