That violates i18n. I'd discourage it.
> -----Original Message-----
> From: Michael McKibben [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 11, 2001 2:47 AM
> To: [EMAIL PROTECTED]
> Subject: Convenience overloads in Category
>
>
> Hi, I was wondering if the following method overloads in
> Category might be
> useful to help ease the burden associated with logXXX() parameter
> construction. Currently, there are two convenience overloads
> per priority,
> e.g.
>
> void info(Object message);
> void info(Object message, Throwable);
>
> What I find myself doing a lot in my code is something similar to the
> following:
>
> category.info("message: " + variable + " is not found");
>
> What if a few extra overloads were added to account for
> multiple message
> parameters, e.g
>
> void info(Object message1, Object message2);
> void info(Object message1, Object message2, Object message3);
>
> Then the user code would be simplified to:
>
> category.info("message: ", variable, " is not found");
>
> The nice thing is that for the common cases of 1-3
> parameters, the "hidden"
> StringBuffer goes away. The overloaded methods inside
> Category could reuse a
> common StringBuffer for string concatenation. Plus, you may
> feel less need
> to wrap your log statements with "category.isInfoEnabled()"
> if statements.
>
> Also, for support for more than three message concatenations, or as an
> alternative to the above idea, an Object[] could be passed to the one
> argument method, and a special renderer could be called upon
> to deal with
> arrays. For example:
>
> category.info(new Object[]{"message", variable, "is not
> found.", "..."});
>
> Would be handled by a default ObjectRenderer similar to:
>
> String doRender(Object o) {
> String message;
> Object[] messages = (Object[])o;
> myStringBuffer.setLength(0);
> for (int i=0; i<messages.length; ++i) {
> o = messages[i];
> message = (o instanceof String)?
> (String)message :
> myRendererMap.findAndRender(o);
> myStringBuffer.append(message);
> }
> return myStringBuffer.toString();
> }
>
> Is all this more trouble than it's worth? I suppose Category
> could be also
> extended to add this behavior as well, but then configuration
> gets a little
> tricky. Thoughts?
>
> --mike
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
