Update on String Templates (JEP 459)

[Jim Laskey]

The current prototype is a single final class, so the statics get folded in.


On Mar 19, 2024, at 4:17 PM, Guy Steele <guy.steele at oracle.com> wrote:

Oh, right, duh. Therefore it really is there, at least in part, to support the (overriding) implementation of the `toString()` instance method that should be in every class that implements StringTemplate?

In this simplified world, do we still really contemplate wanting to support multiple implementations of StringTemplate, as opposed to just making it a class?

On Mar 19, 2024, at 3:07 PM, Jim Laskey <james.laskey at oracle.com> wrote:

Note: the static implementations are there because you can’t default overridden methods. In this case methods inherited from Object.


On Mar 19, 2024, at 3:59 PM, Guy Steele <guy.steele at oracle.com> wrote:



On Mar 19, 2024, at 2:33 PM, Brian Goetz <brian.goetz at oracle.com> wrote:


Here I set forth your three examples with new names that are related
to those already used in the existing preview implementation of
StringTemplate in JDK 21 (and JDK 22—I just checked). I do this not to
suggest that these other names should be used, but only in the hopes
of reducing confusion as we begin this discussion. Later we can decide
whether the names “process” and “interpolate” and “combine” should be
changed (possibly all into the same single name).

    // on String
    static String process(StringTemplate)    // previously STR

    // on StringTemplate
    String interpolate()                             // STR, instance/suffix version
    static StringTemplate combine(StringTemplate...) // + for string templates


Maybe I’m missing something, but: Why do we need both `String::process`
and `StringTemplate::interpolate`?  What are the use cases?


For a similar reason we currently have String::valueOf(int) and Integer::toString(int).  In some use cases, the "prefix" usage (static method) feels more natural, whereas in others, the "suffix" usage (instance method) feels more natural.

Even if we end up with only one, I would rather not bias towards "of course it is the static version" at this early point; I am trying to sketch out scope right now.

Well, we can start by first examining the methods of the StringTemplate interface in JDK 22:

Factory methods:
static StringTemplate of(String)
static StringTemplate of(List<String>, List<?>)
Accessors:
List<String> fragments()
List<Object> values()
Combining:
* static StringTemplate combine(StringTemplate... stringTemplates)
static StringTemplate combine(List<StringTemplate> stringTemplates)
String interpolation:
* default String interpolate()
static String interpolate(List<String> fragments, List<?> values)
Conversion to diagnostic string:
static String toString(StringTemplate stringTemplate)
Processing:
default <R, E extends Throwable> R process(StringTemplate.Processor<? extends R,? extends E> processor)

I reckon we still need the factories and accessors.

As for combining, the first one (indicated by *) is on Brian’s list, and I am not sure the second one is needed, but it is not a big deal to include it, I suppose.

As for string interpolation, the first one (indicated by *) is on Brian’s list, and I am not sure we need the second, static one: is it not equivalent to `StringTemplate.of(frags, vals).interpolate()`? Is it there just to avoid allocating a StringTemplate, or perhaps to support the implementation of the instance method `interpolate()`?

I am not sure why this static `toString` method is there, rather than relying on the `toString()` instance method that every object must support. Is it present to support the implementation of the instance method? I guess I don’t see why this is not just a `default` implementation of the instance method.

I reckon we don’t need this particular `process` method in a design that does not have the `StringTemplate.Processor` interface.

So of these ten methods, I guess we surely need 6, don’t need 1, and I am uncertain about 3 for various reasons.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20240319/7c9398b3/attachment.htm>