Update on String Templates (JEP 459)

[Maurizio Cimadamore]

Of course a static method is enough (I find the name “process” not very 
clear on what that method does though).

One case where the instance syntax comes out on top if in method context:

|foo($"Hello, \{world}".xyz()) |

Which reads better than:

|foo(xyz($"Hello, \{world}")) |

at least IMHO (no doubly nested parens).

Even though, at the end of the day, interpolation is just a processor, 
just a method which takes a StringTemplate and returns a String, it is 
also a very common one, so allowing for an instance method could be a 
possible way to offset the loss of the STR syntax.

Maurizio

On 19/03/2024 18:33, Brian Goetz 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.
>
>
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240319/4135d0fc/attachment-0001.htm>