Ceki,
SLF4J has methods that take discrete parameters so that it can avoid
constructing the LoggingEvent if it does’t need to. This kind of turns that
upside down. That said, Lambdas create an object that contains the expensive
logic to execute, without executing that logic until necessary. Typically the
cost of creating the Lambda objects is insignificant. Log4j 2 already supports
Lambdas while still only requiring Java 7 - we just use our own Supplier
interface.
I am not sure I see how what you are proposing here correlates at all to what
using lambda expressions achieves. In your proposal the user has to construct
the LoggingEvent before calling the log method, which implies that the whole
thing needs to be wrapped in an if (logger.isDebugEnabled()) block. Lambdas
free you from that.
OTOH, it was proposed to you years ago that SLF4J accept Messages [1] - as
Log4j 2 does now. I believe this yields more gains than what one would get with
your proposal. I think exposing a LoggingEvent that includes the Marker and
Level is a bad idea. While the Message interface allows for users to log
complex objects, it does so by only solving for that problem and does not
introduce fields that really have nothing to do with the message content being
delivered.
Although a bit off topic, I should point out that if SLF4J provided an
AbstractLogger class that the impact of adding new methods to the Logger
interface would pretty much be a non-issue. Most of the time the class
extending AbstractLogger wouldn’t need to change. Currently the Log4j 2 API has
192 methods. If AbstractLogger is extended only 7 methods need to be
implemented.
Ralph
[1] http://slf4j.42922.n3.nabble.com/Benefits-of-Message-objects-td3316674.html
<http://slf4j.42922.n3.nabble.com/Benefits-of-Message-objects-td3316674.html>
_______________________________________________
slf4j-dev mailing list
slf4j-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-dev
