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 <[email protected]> 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.) > >
