StringTemplates deferred evaluation

[David Alayachew]

I feel like that would be on the logging libraries to provide, not so much
the language.

Let's say that your problem (as I understand it) is like this.

log.debug("metrics =
\{this.expensiveComputationThatNormallyWouldntRunUnlessYouActivateDebug()}");

Sounds to me like the solution is this instead.

log.debug(() -> "metrics =
\{this.expensiveComputationThatNormallyWouldntRunUnlessYouActivateDebug()}"
)

So, your logging library just needs to add a new overload for a
Supplier<StringTemplate>, and then this problem is solved entirely outside
of the language. Log4J and friends are pretty good about keeping up with
new additions, so it should not take long.

I know it's a little less convenient, but doing it this way helps keep out
complexity from the feature, and only introduces it where necessary (and
it's only necessary at use-site).

Would this meet your needs?

On Sun, Mar 17, 2024 at 11:15 AM Justin Spindler <justin.spindler at gmail.com>
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/d95c84ed/attachment.htm>