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

[Tomasz Linkowski]

Alan,  Rémi,

If you're still interested in providing transform-like behavior for
CharSequence, there's a fairly neat (I hope) way to do that.

The idea is to use the following helper functional interface for forwarding
to the already added String.transform:


@FunctionalInterface
interface Transformer<T> {
  <R> R by(Function<? super T, ? extends R> f);
}


public interface CharSequence extends Transformable {
  // ...
  Transformer<? extends CharSequence> transformed();
  // ...
}


public final class String implements /*...*/ CharSequence {
  // ...
  @Override
  public Transformer<String> transformed() {
    return this::transform;
  }
  // ...
}


Usage:

CharSequence transformed = charSeq
        .transformed().by(s -> StringUtils.defaultIfBlank('0')) // sample
Function
        .transformed().by(...)
        .transformed().by(...);


If you find it interesting, it's described in detail in my blog post:
https://blog.tlinkowski.pl/2018/transformer-pattern/

Regards,
Tomasz Linkowski


On Fri, Sep 21, 2018 at 12:42 PM 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
>


-- 
Pozdrawiam,
Tomasz Linkowski