Update on String Templates (JEP 459)

[Guy Steele]

Good; thanks for explaining the motivation. This all sounds right to me.

Other than that, I cannot think of any other clearly needed operations on templates. They are essentially a specialized sequenced immutable aggregate structure, but a lot of the generic operations one might want on such structures (map, reduce, sort) don't seem terribly relevant to templates.

> On Mar 19, 2024, at 4:05 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 
>> Well, we can start by first examining the methods of the StringTemplate interface in JDK 22:
>> 
>> I reckon we still need the factories and accessors.
> 
> I would like to question the "factories" part of that.  As Ron has pointed out, having string / string template literals be the sole source of fragments in STs preserves a valuable non-tainting property.  (Remi has expressed reasonable concerns that we will not be able to preserve this property in the end, but it is worth trying.)   This is part of the motivation for `combine`; preserving this safety invariant as well as providing a convenient operation.
> 
>> 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()`?
> 
> There is a performance aspect to this.  The details vary from the initial version that we previewed previously to the latest proposal, but the essence is the same: if we can tie a string template instance to its point of capture in the source code, then we can cache a method handle that has full knowledge of the template fragments and the embedded expression types to optimize the conversion.  If the same capture site captures a template with different embedded expressions (such as code in a loop, or the toString method of some object that uses templates), we can reuse that MH.  There are many possible optimizations here (and even more for a complex processor like FMT, that has to do a lot of work when scanning the format string.)
> 
> If a ST has its origin in an actual capture site, as a ST literal does, then we have a place to cache this.  The current design uses the invokedynamic linkage state, but there are other possible places too.  Calling `StringTemplate.of(frags, vals).interpolate()` has no such place to cache the analysis of the constant parts (fragments and expressions types.)
> 
>> 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 think that's right (Jim might have some context here.)
> 
>