[slf4j-user] Re: Re: Varargs for Logger methods

[Kostis Anagnostopoulos]

On 2/16/06, Ceki Gülcü <listid at qos.ch> wrote:
> ...
> Oh, OK. I was thinking of replacing
>
> public interface Logger {
>
>   void debug(String msg);
>   void debug(String msg, Object o);
>   void debug(String msg, Object o1, Object o2);
>   void debug(String msg, Object[] oArray);
>   ....
> }
>
> by the more economical
>
> public interface Logger {
>   void debug(String msg, Object ... args);
>   ....
> }
>
> But the above is not what you had in mind.

I hadn't thought out all the details of my suggestion.
Of course i agree with the class you describe!

>
> It looks like replacing a single method, that is debug(String, Object[]) by
> debug(String, Object...), would be quite feasible, especially since it
> seems to preserve both compile time and run time compatibility. Existing
> clients would compile fine against a modified version of SLF4J. Just as
> importantly, client classes compiled against an older version of SLF4J
> would run fine with modified versions of SLF4J (assuming JDK 1.5).
>
> In a few years time when JDK 1.5 gains wider deployment share, we can
> revisit the issue.

Well, there is something that we can get prepared from now:

What would the method would look like, when using exceptions
AND params together?
Would it be like:

    void debug(String msg, Throwable t, Object... params);

then we woule separate the 'msg' argument from the correlated 'params'
with the exeception, and that is confusing (does the exception
participate in the substitution, or not?).


I suggest the next forms to solve the confusion:

    void debug(Throwable t, String msg, Object... params);
    void debug(Throwable t);
    void debug(String msg);

While this form looks weird, it only has 1 problem:
Incompatible "look'n feel" with other APIs

But it has 2 more merits:
* First, an exception can be placed as a 'param' without the cast to (Object),
like next (more natural) form:

    debug("Problems due to: {}!", ex);
instead of:
    debug("Problems due to: {}!", (Object)ex);

* Second, since msgs some time are wide, when using the current form,
we cannot see easily whether the exception is included in the log
(it's too far on the right).
The next would be a nice example (only if mail-middleman did not wrap
long lines):

    try {
        ....
    } catch(SomeException ex) {
        getLogger().debug("I'm not sure whether to include the
exception stack at the end of this message", ex);
        throw ex;
    }

There would be no such prolem to spot whether the exception is included in the
next invocation:

        getLogger().debug(ex, "I'm not sure whether to include the
exception stack at the end of this message");

In conclusion, since this is a new API, it is now the time for such a change
(even though in RC6).
Please consider the form i suggest, regardless of whether a transition
to java 1.5
is 1, 2 or 6 years, or months, later.

ankostis

>
> >     ankostis
>
> --
> Ceki Gülcü
>
> _______________________________________________
> user mailing list
> user at slf4j.org
> http://slf4j.org/mailman/listinfo/user
>