commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Schindl <>
Subject Re: [lang] VariableFormatter issues
Date Wed, 26 Apr 2006 11:05:53 GMT
Gary Gregory wrote:
> Hello:
> I wonder if in the interest of getting version 2.2 out the door we
> should keep VariableFormatter as-is. Anyone who likes the subclass can
> obviously use it. If the feature is easy to add, we don't have to
> discuss the following for post-2.2:
> - Does the VariableFormatterWithFormating functionality belong in
> VariableFormatter or should it be a subclass.
> - It seems like we could also extend the current ${} syntax to include
> the VariableFormatterWithFormating feature. Where this gets tricky and
> could become difficult is if we cannot reuse MessageFormat.format. 
> Tom (and all): 
> Have you considered changing VariableFormatter itself to provide the
> feature?

Yes but I thought if you want to turn on/off variable formatting (e.g.
because of performance issues) the API would get too bloated, you need
to duplicate all static functions, wouldn't you?

> Would changing MapVariableResolver only do the trick?

Yes, I think so but I wasn't sure about the side-effects.

> The implementation in the ticket subclasses VariableFormatter, why not
> subclass just MapVariableResolver only?

Because of the above mentionned bloated API if you want to turn it
on/off in VariableFormatter.

> To make the code more reusable we should be open to making the inner
> classes stand alone.

That would be a great thing to have.

> Gary

I think adding this formatting to VariableFormatter makes it more
useable e.g. for displaying debugging messages than it would be now.


View raw message