<div dir="ltr"><div>> The issue is that deferred evaluation could provide a gapping vulnerability.</div><div><br></div>I'd be curious about this vulnerability.<div><br></div><div>> You can get the effect you want by using Suppler objects as embedded expressions.</div><div><br></div><div>Sure, but that increases the amount of code that the developer needs to write pretty substantially, especially since there are no natural types for lambdas so the developer would have to assign that to a typed variable ahead of time or cast explicitly to a Supplier in the embedded expression.</div><div><div style="color:rgb(8,8,8)"><pre style="font-family:"Cascadia Code PL",monospace;font-size:9.8pt"><span style="color:rgb(6,125,23)">FOO."This is a test: \{</span>(<span style="color:rgb(0,0,0)">Supplier</span><<span style="color:rgb(0,0,0)">Integer</span>>) () -> calc(x, y, z)<span style="color:rgb(6,125,23)">}"</span></pre><pre style="font-family:"Cascadia Code PL",monospace;font-size:9.8pt">It's fine if this isn't a scenario that the team hasn't considered, or believes that there are sufficient workarounds.  I will say that it's not that uncommon that I find logging code at trace or debug levels that ends up calculating complex strings (even stacktraces) which is noticeable enough to cause performance regressions.  We do try to emphasize using the Supplier overloads of log4j methods to avoid that calculation, but it's certainly not a pit of success.</pre></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 17, 2024 at 1:28 PM Jim Laskey <<a href="mailto:james.laskey@oracle.com">james.laskey@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There was a discussion about this on this list a while back. The issue is that deferred evaluation could provide a gapping vulnerability.<br>
<br>
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. <br>
<br>
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). <br>
<br>
— Jim<br>
<br>
📱<br>
<br>
> On Mar 17, 2024, at 12:14 PM, Justin Spindler <<a href="mailto:justin.spindler@gmail.com" target="_blank">justin.spindler@gmail.com</a>> wrote:<br>
> <br>
> <br>
> 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?<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> <br>
</blockquote></div>