Presentation at JCrete.org

[Brian Goetz]

> This does not mean I think having side effects to string interpolation 
> is a good idea, and it also doesn’t mean that you can’t get this same 
> safety with side effect free interpolation. If the logger’s log 
> methods have an overload for a `Templated` object that would be 
> returned by the `LOG.”...”` interpolation, one could just not template 
> expand any `Strings` passed to the logger.
>
> Having `logger.info(LOG.”value: \{value}”)` is a bit more unwieldly to 
> some than just `LOG.”value: \{value}”`, so I think it’s gonna be 
> inevitable that people are gonna add sideeffects somewhere to 
> interpolations.
>
>

I think you've laid it out here: you acknowledge that having LOG."stuff" 
*do* the logging is a bad idea, when there's an entirely sensible 
alternative that gets you the desired safety and deferral of expensive 
formatting:

     logger.info(LOGMSG."...")

This is a responsible API design that meets the goals of its use case.  
The real problem, as you've put it, is programmers that put concision 
above clarity:

> Having `logger.info(LOG.”value: \{value}”)` is a bit more unwieldly to 
> some than just `LOG.”value: \{value}”`, 

Yes, bad programmers will say "the right way is a bit more unwieldy, so 
of course I will do it the other way".  Bad programmers will design bad 
APIs and misuse good ones all in the name of saving a few characters (or 
a few cycles when it doesn't matter.)  Let's just call it what it is, 
and try to set a better example.


On 7/24/2023 8:26 AM, forax at univ-mlv.fr wrote:
>
> The problem of logger.info(LOG.”value: \{value}”) is that the logger 
> receive a string, not a string template

No, not necessarily.  LOG can be a (purely functional) 
TemplateProcessor<LogMsg>, which defers rendering the string until it is 
actually logged:

     logger.info(LogMsg msg)

Then you have a free choice over where to put the validation (in LOG, or 
in the logger.)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230724/e709adcd/attachment-0001.htm>