JEP 430 String Templates, some weird scenarios feedback

[Brian Goetz]

> On Sat, 17 Jun 2023 at 14:40, Brian Goetz <brian.goetz at oracle.com> wrote:
>
> We have three descriptions of "template" so far:
> 1) a "thing with holes"
> 2) *a thing to be filled in* (an empty Mad Lib)
> 3) a completed Mad Lib
>
> The first two are the same surely? An immutable thing with specific
> places that data needs adding. My view is clear - when you fill in a
> Mad Lib, it is no longer a template.

Surely not!  The first thing (also be called a "stencil"), which is used 
to stamp out identical shapes but the mutation happens elsewhere: you 
use the immutable template to mutate the paper. Whereas the second thing 
(also called a "form") is mutated when you fill it in.  This mutability 
is monotonic; the template goes from "blank" to "filled in", and not 
backwards.  (Naming things is hard.)

Regardless, our string templates are like #3.

>> At root, I think what you're saying is "I think BoundTemplate or
>> FilledInTemplate or TemplateWithValues might be a better name than
>> StringTemplate", which is a totally reasonable opinion!

Great, I take your reply as concurring that this is your main concern :)

> Separately, I'm arguing that the "unbound" template should be exposed
> as well through the API. If you wanted to defer that, you could do so
> long as the terminology adopted now was "bound template" or similar.

That is designing an entirely other feature (with plenty of additional 
complexity.)  But, you can get the effect of that feature with the 
feature we have; Jim has posted examples of how to use string templates 
for things like mail merge.

>> No one would be surprised in the least that when we eventually call
>> toSTring on the StringBuilder, that we captured the value 2 rather than
>> the variable x.
> Agreed. But it is well understood because it looks like a method call.

A template expression is like a method call (because it is sugar for 
one), so this is point about which education is needed.
> 2) It doesn't look like a method call, so the learned knowledge of
> values doesn't apply

It looks more like a method call (see the dot!) than anything else in 
the language, and this choice was not accidental.  It will be unfamiliar 
the first time you see it, and people may make wrong guesses, but that's 
true of every new feature.

> FWIW I do feel the UPPER."" part of the syntax of this feature isn't
> helping understanding. But I'll avoid making a syntax suggestion
> unless asked to.

But the UPPER part isn't even part of this feature!  That comes from 
Java 1.0.  STR and RAW and friends are *just static final fields*, and 
the UPPER part comes from the long-standing naming convention that 
constants are ALL_CAPS.

Indeed, we expect it to be a happy discovery when developers realize 
that STR is not language syntax [*], but just an ordinary constant of 
type TemplateProcessor.  You could, for example, do this:

     TemplateProcessor<String> alt = STR;
     String s = alt."Hello \{name}";

The thing to the left of the dot is a receiver, plain and simple. Any 
expression of the correct type will do; it's as if "..." is a method.  
(Which is why it has method call semantics.)  STR just happens to be a 
convenient constant for common behavior.


[*] Some minor magic in that this field is auto-static-imported