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)