<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 19, 2024 at 2:13 PM Guy Steele <<a href="mailto:guy.steele@oracle.com">guy.steele@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
On general principle, I would agree about instance methods often being better than static methods for various reasons, other things being equal.
<div><br>
</div>
<div>But in this specific discussion we have heard concerns about confusing templates with string interpolation. When it comes to safety of (say) SQL processing, which of the following would we prefer:</div>
<div><br>
</div>
<div><font face="Menlo"><span style="white-space:pre-wrap"></span>SQL($"SELECT * FROM \{tableName} blah blah blah”.xyzpdq());</font></div>
<div><font face="Menlo"><br>
</font></div>
<div>
<div><font face="Menlo"><span style="white-space:pre-wrap"></span>SQL(xyzpdq($"SELECT * FROM \{tableName} blah blah blah”));</font></div>
</div>
<div><br>
</div>
<div>The first one avoids nested parentheses. The second one says right up front, “Danger, Will Robinson, danger! The template will not be processed in the way you might think!"<br></div></div></blockquote><div><br></div><div>If xyzpdq() is STR/interpolate/join, and SQL() only accepts StringTemplate (as it should), then either one will fail to compile.</div><div><br></div><div>I am increasingly convinced that the right framing of String vs StringTemplate is not a family relationship, like String vs CharSequence, but an arms-length relationship like String vs byte[]. 
I would extremely rarely write two same-named overloads, one accepting byte[] and the other String.</div><div><br></div><div>While String and StringTemplate (and byte[]) are strongly related, and you can readily create any one from any other, they serve distinct purposes and have very different security properties. Like byte[], a StringTemplate can contain mutable data, and also like byte[], you need additional context to safely and correctly process one into a String or other object. Unlike both byte[], and String, a StringTemplate contains arbitrary objects with arbitrary behaviors, which gives StringTemplate a completely different threat model.<br></div><div><br></div><div>For all of these reasons, I would extremely rarely write same-named overloads, one accepting String and the other StringTemplate. A client having to deal with a compiler error if they call the wrong one is a feature.</div><div><br></div><div>
<div>I think the release notes and documentation for 
StringTemplate should explicitly recommend different names for methods 
accepting String vs. StringTemplate, rather than same-name overloads, 
for both safety and clarity.</div>

</div><div><br></div><div>Cheers,</div><div>Clement Cherlin<br></div></div></div>