[External] : Re: [string-templates] Accidental use of StringTemplate instead of string

[Tagir Valeev]

Thanks!

On Mon, Oct 24, 2022 at 1:58 PM Jim Laskey <james.laskey at oracle.com> wrote:
>
> Tagir,
>
> I’ve added RAW as a standard template processor. It is not statically imported automatically (import static java.lang.template.StringTemplate.RAW; required). I would recommend that “on inspection” giving the user the choice of;
>
> 1.
> STR."..."
> 2.
> RAW."..."
> 3.
> //noinspection IntentionalRawStringTemplate (or somesuch)
> "..."
>
> The intention of the statement below is clear. Would inspection ignore this case?
>
>     StringTemplate st = "...";
>
> Cheers,
>
> — Jim
>
>
>
>
> On Oct 21, 2022, at 6:17 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>
> I suppose I should have mentioned you can do this by convention as well. Define RAW and use to highlight where StringTemplates are needed.
>
> TemplateProcessor<StringTemplate> RAW = st -> st;
> StringTemplate template = RAW.”…”;
>
> 📱
>
> On Oct 21, 2022, at 6:03 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>
>  It’s not unreasonable. In fact, the early POCs had a RAW processor.
>
> I would still like to see how it plays out as-is during Preview. Others might develop other opinions or ideas.
>
> Cheers,
>
> — Jim
> 📱
>
> On Oct 21, 2022, at 5:34 PM, Tagir Valeev <amaembo at gmail.com> wrote:
>
> 
> Hello!
>
> On Fri, Oct 21, 2022, 15:05 Victor Nazarov <asviraspossible at gmail.com> wrote:
>>
>> Hello!
>>
>> I think one suggestion that fixes stated problems was already proposed before and I heard no arguments against going this route
>> ...
>>
>> One suggestion that fixes this problem is to forbid bare template strings without policy-prefixes and instead introduce some policy that returns TemplateString itself.
>>
>> ````
>>     StringTemplate tmpl = TMPL."\{x} plus \{y} equals \{x + y}" ;
>>     String s1 = tmpl.apply(STR);
>>     String s2 = STR."\{x} plus \{y} equals \{x + y}";
>>     assertEquals(s1, s2);
>> ````
>>
>> In this world the following can be observed:
>>
>> ````
>>     System.out.println(STR."\{x} plus \{y} equals \{x + y}"); // Prints "10 plus 20 equals 30"
>>     System.out.println(TMPL."\{x} plus \{y} equals \{x + y}"); // Prints "StringTemplate{segments = ["", " plus ", " equals "], values = [10, 20, 30]}"
>>     System.out.println("\{x} plus \{y} equals \{x + y}"); // COMPILATION ERROR: error: unrecognized escape sequence '\{', policy is required for template strings
>> ````
>
>
> Sounds really good to me. In any case, template expression is not directly substitutable. E.g. you cannot replace
>
> STR."Hello \{user}"
>
> with
>
> StringTemplate t = "Hello \{user}"
> STR.t
>
> Instead, you need to desugar to a method call, like STR.process(t). I think that in Java, all the expressions we had before were substitutable in this sense: you could extract them to variable, and use that variable instead. So it would be more consistent to avoid naming the right part of process template expression as expression itself. I would suggest the following:
>
> If parser meets a dot that follows single double quote, or triple double quote, then the right part is always a string template, or a text blocks template, and the whole thing including qualifier is process template expression. Template may have no substitutions at all, in this case it looks exactly like string or text block, but it's a template. Template is not an expression and cannot appear in any context other than in process template expression.
>
> This simplifies grammar somewhat, as we say that template without placeholders is still a template. Also, having an identity template processor, like TMPL proposed by Victor, makes it possible and consistent to instantiate the StringTemplate object that contains no placeholders. The cost is five characters (TMPL.) necessary for presumably rare and advanced uses of templates where one wants to store it without immediate processing.
>
> What do you think?
> Tagir Valeev
>
>