>
> There are several reasons.
>
> 1) With MessageComposer one can write:
>
> logger.debug("My name is {}.", name);
> logger.debug("My name is {}. I am {} years old", name, age);
>
> instead of
>
> logger.debug("My name is {0}.", name);
> logger.debug("My name is {0}. I am {1} years old", name, age);
>
> with java.text.MessageFormat.
>
Actually, I was thinking along the lines of:
logger.debug("My name is {1}. I am {0} years old", new Object[]{new
Integer(30}, "Paul"});
Which is more cryptic, no arguments there, but more flexible:
* It can handle practically unlimited # of args
* Order of args can be different from the order they are displayed.
> I think the omission of the numbered parameters makes writing debug
> statements quicker and easier for the user. You have to try it 4 or 5
> times to notice the difference but it becomes quite noticeable after a
> short while.
>
It would surely be easier to use, I cannot argue that, but, how many
arguments will we support? 2? 5? 10? It seems limiting to me, despite the
ease of use.
Any comments on that?
> 2) Since MessageComposer has a smaller scope, it should perform its
> parsing duties significantly faster then java.text.MessageFormat.
> Moreover, since we have access to the internals of MessageComposer, we
> can modify it so that it caches its results. Thus, the next time a
> given message needs to be output, we can use the parsed structure and
> economize the work involved in parsing the message.
>
Yes, we (and by that I mean you... :) ) can probably do a better job of
implementing it.
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
