[slf4j-dev] [JIRA] Updates for SLF4J-526: Idea for fluent API improvement

[QOS.CH (JIRA)]

SLF4J / SLF4J-526 [Open]
Idea for fluent API improvement

==============================

Here's what changed in this issue in the last few minutes.

There is 1 comment.

View or comment on issue using this link
https://jira.qos.ch/browse/SLF4J-526

==============================
 1 comment
------------------------------

Adrian Shum on 06/Jan/22 7:54 AM
I do understand the concern.

For me, it is also a trade-off for code readability.  Code becoming harder to read as our brains have been trained to read the logging by message-with-placeholder, followed by values.

Given fluent API are aimed for construction in more dynamic way, we may still face problem that the code will not have {{.log(message)}} called. 

I don't see reason why we couldn't provide both options to users: They could normally use {{.log(message)}} if they want a "safer" practice, but they could still choose another approach if they want readability.

Another idea, although may look less elegant, is to make use of lambda to even omitting needs of calling {{log()}} :
{code:java}
logger.atDebug(l->l.message(Temperature of {} rise from {} to {}")
      .arg(country)
      .arg(oldTemp)
      .arg(newTemp));

 // More dynamic logging event construction, where .log(...) could be missed even easier
logger.atDebug(l->{ 
        l.message(Temperature of {} rise from {} to {}")
                .arg(country)
                .arg(oldTemp)
                .arg(newTemp);
        for (Entry<String, String> e: myMap) {
            l.addKeyValue(e.getKey(), e.getValue());
        }
     });

{code}
 

Apart from omitting need of needing user to call {{.log()}} (hence, safer API), this also allows potential optimization in future, to reuse same (or a ThreadLocal one?) Log Event Builder across multiple calls, instead of creating new builder every time.

 

(Can help on the lambda approach too if you think it looks fine)


==============================
 This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)