New string template approach.

[Brian Goetz]

On Mar 11, 2024, at 5:17 AM, Duncan MacGregor <duncan.macgregor at servicenow.com<mailto:duncan.macgregor at servicenow.com>> wrote:

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.


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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240311/5dd9880c/attachment-0001.htm>