[slf4j-dev] [Bug 31] Varargs for Logger methods

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=31

Ceki Gulcu <listid at qos.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |listid at qos.ch

--- Comment #91 from Ceki Gulcu <listid at qos.ch> 2011-09-07 15:57:36 CEST ---
Fixing common functionality in an abstract class can alleviate some of the
compatibility issues. The idea of reducing adapter implementations to two
simple methods is quite brilliant. Nevertheless, Joern makes good points
regarding early formatting. Message parameters must reach the logging backend
unchanged whenever the backend has the appropriate hooks, e.g. logback.

I am guessing that the idea of reducing adapter implementation can still be
achieved albeit with different method signatures. 

Now imagine the following thought experiment. Assume that come up with some
code structure which reduces adapter implementations two a handful of methods
for all backends. At a later stage, assume we wish to enhance the
org.slf4j.Logger interface with new functionality, say support for Joern's
Message objects. The aforementioned methods would need to be modified to
support Message objects breaking compatibility with existing adapter
implementations. 

I see 3 possibilities to dealing with changes in SLF4J:

0) disallow any meaningful changes to SLF4J
1) allow for breaking compatibility for adapter implementations (as done
historically in SLF4J)
2) come up with an abstraction so flexible that it is future proof for the next
10 years. 

0 and 1 are doable. 2 requires great foresight.

-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.