<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 11, 2024, at 5:17 AM, Duncan MacGregor <<a href="mailto:duncan.macgregor@servicenow.com" class="">duncan.macgregor@servicenow.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="margin: 0cm; font-size: 11pt; font-family: Aptos, sans-serif; caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
The other thing I’d be interested to know in this new approach is how StringTemplates inserted as values into other templates will be treated. Simply as StringTemplate objects in the values list, or will they produce a string template that has been flattened?
The new approach feels like it will encourage this approach of combining fragments and is likely to be something that many processors are going to need to handle.</div>
<br class="Apple-interchange-newline">
</div>
</blockquote>
</div>
<br class="">
<div class="">This is a significant point. In the previous design iteration, this never came up, because templates were processed by processors so early they didn’t have much of a chance to be combined with other templates. </div>
<div class=""><br class="">
</div>
<div class="">Intuitively, an unprocessed string template is in some DSL “language”; a string template suitable for processing by FMT / String::format (which expects embedded format specifiers like %d) is in a different “language” than one that is destined
to be a SQL query (requires balanced quotes, etc.) The natural interpretation is that when we embed an ST fragment in another ST, the embedded ST fragment should be in the same “language”, and that “processors” should flatten embedded STs. </div>
<div class=""><br class="">
</div>
<div class="">If you are using string templates in a code generator, where you build up a class out of smaller fragments (possibly recursively), this works quite naturally; we can start with a class template “class \{name} { \{body} }” and build the body separately,
and the body may be built from method templates whose implementation is further embedded. Similarly, SQL queries are often built from pieces (which columns, which tables, join criteria, filter criteria) are often built separately and combined; this works
cleanly with embedding “sub-templates” as well. Similar with recursive formats like JSON.</div>
<div class=""><br class="">
</div>
<div class="">What this means is that “processors” need to be prepared to see embedded STs, and flatten accordingly. There may be some library helpers for this; TBD.</div>
</body>
</html>