<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">The goal here is to help users
        learn, through feedback, that a StringTemplate is not a string,
        but a recipe for one, and if you want to get that string, you
        have to cook it.  <br>
        <br>
        One way to help that along might be to have the toString look
        more like that of a record:<br>
        <br>
            StringTemplate{ segments = [ blah blah ], values = [ blah
        blah ] }<br>
        <br>
        which will reinforce that you printed out a recipe and not the
        thing it describes.<br>
      </font></font><br>
    <div class="moz-cite-prefix">On 10/20/2022 10:44 AM, Tagir Valeev
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAE+3fjbL0UnKi5jiS6hBjV2+-6L6fMiGGk5o6Ga67AzjvokQ8g@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Hello!

As stated in JEP 430 text, the string template is a well-formed
expression of StringTemplate type. Also, toString() method of
StringTemplate prints a debug-friendly representation like
[fragments](values) which is not intended for actual use. I can
imagine that the following mistake may happen often, especially by
inexperienced developers, or developers with background in other
languages:

int x = 10, y = 20;
System.out.println("\{x} plus \{y} equals \{x + y}");

Output expected by programmer: 10 plus 20 equals 30
Actual output (successfully compilable): ["", " plus ", " equals ",
""](10, 20, 30)

As an IDE vendor, we can surely provide an inspection for some
well-known methods like PrintStream#println(Object) with a quick-fix
to add a STR. prefix. However, not everybody uses IDEs. Probably the
language itself could help here somehow? E.g., uses of StringTemplate
where the Object type is expected might trigger a warning. This is
similar to array toString(), and every static analyzer has an
inspection about this. Honestly, I don't know a good solution but I
feel that it's not a good idea to introduce a new error-prone
construct, which is compilable and runnable, could be mistakenly used
and doesn't make sense.

As we are here, is it planned to specify StringTemplate equals and
hashCode? It's naturally a tuple of (fragments, values) lists, so
equals and hashCode could be defined. Also, current draft [1] suggests
that this is a non-sealed interface. Is it really intended to allow
third-party implementations?

Sorry if these questions were already discussed, I might skip some
discussions. I would be happy to see the pointers to previous
discussions.

With best regards,
Tagir Valeev

[1] <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~jlaskey/templates/docs/api/java.base/java/lang/template/StringTemplate.html">http://cr.openjdk.java.net/~jlaskey/templates/docs/api/java.base/java/lang/template/StringTemplate.html</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>