StringTemplates deferred evaluation

[Brian Goetz]

Yes, this was considered (because of the exact same use case you mention 
-- logging).  It turns out to be one of those "seems briefly attractive" 
ideas.

It turns out that *evaluating* the embedded parameters is almost always 
cheap; it is the production of the final string, including calling 
`toString` on reference parameters that are not already String, is the 
expensive part.  (Embedded expressions are usually scalars, which are 
ultra-cheap to capture.)  So you don't need laziness in capturing the 
template; you need laziness in evaluating it.  And such laziness is best 
made explicit.

And loggers, as you point out, often provide a Supplier<String> 
overload, allowing you to do:

    logger.info(() -> STR."...")

The real problem is that the user is being asked to apply the processor 
to the template too early.  A better strategy is to let the Logger 
accept StringTemplate:

     logger.info(RAW."...")

Which feeds into the current evolution direction being discussed, just 
with a slightly different syntax.





On 3/17/2024 11:09 AM, Justin Spindler wrote:
> I was toying around with the second preview of StringTemplates and I 
> had a question regarding their design.  I was wondering if it had been 
> considered for the embedded expressions to be evaluated lazily?
>
> One of the first use cases that came to mind when I was exploring 
> StringTemplates is logging.  That is an extremely common case where we 
> want to produce a form of interpolated value, and the current syntax 
> generally has the same concerns that a formatted string would, in that 
> the inputs are removed from where they are defined within the message 
> format. However, if the log message is below the log level 
> threshold you generally don't want to incur the cost of building the 
> message, including evaluating those embedded expressions.  Log 
> libraries typically offer a mechanism to defer evaluation via 
> Suppliers, but that feels like it would be a challenge to use within 
> StringTemplate.
>
> C# is an example of a language that offers this functionality via 
> FormattableString, which gives a method the ability to choose whether 
> or not to interpret the template or evaluate the expressions.  That 
> allows logging below threshold to be more or less a no-op.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240317/ee49ea34/attachment.htm>