[External] : Re: StringTemplates deferred evaluation

[Jim Laskey]

Good point. I’ll play with that. 
📱

> On Mar 18, 2024, at 5:52 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ----- Original Message -----
>> From: "Jim Laskey" <james.laskey at oracle.com>
>> To: "Justin Spindler" <justin.spindler at gmail.com>
>> Cc: "amber-dev" <amber-dev at openjdk.org>
>> Sent: Sunday, March 17, 2024 6:28:07 PM
>> Subject: Re: StringTemplates deferred evaluation
> 
>> There was a discussion about this on this list a while back. The issue is that
>> deferred evaluation could provide a gapping vulnerability.
>> 
>> You can get the effect you want by using Suppler objects as embedded
>> expressions. I posted a logging example using a timestamp Supplier. The Suppler
>> was evaluated by the processor.
>> 
>> In the new world we are working on, the same thing can done. The plan is to
>> provide a mapValues method as in st.mapValues(v -> v instanceof Supplier S ?
>> S.get() : v).
> 
> Hello Jim,
> I think i would prefer the method interpolate to take a Function<Object, String> instead of having a method mapValues, to force users to think about escaping at least the values even if users can still use st.interpolate(String::valueOf).
> 
>> 
>> — Jim
>> 
>> 📱
> 
> regards,
> Rémi
> 
>> 
>>>> On Mar 17, 2024, at 12:14 PM, 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.
>>>