StringTemplates deferred evaluation

[David Alayachew]

The cost would be no different than evaluating a StringTemplate lazily.
Utlimately, log.debug(blah) is still a method call, and therefore, some
object is going into the method. Whether we evaluate the StringTemplate
lazily or the Supplier<StringTemplate> lazily is largely the same thing.

Or am I misunderstanding you?

On Sun, Mar 17, 2024 at 12:28 PM Anatoly Kupriyanov <kan.izh at gmail.com>
wrote:

> But the "() ->" thing is still a runtime object to be allocated on the
> heap... or is the JIT smart enough to always optimize it out?
>
> On Sun, 17 Mar 2024 at 16:17, David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> 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.
>>>
>>>
>>>
>
> --
> WBR, Anatoly.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240317/a1c83879/attachment-0001.htm>