Gary Gregory wrote:
I would like us to reconsider the use of the VariableResolver interface
for VariableFormatter.
It seems that this is a cleaner design that does not force subclassing
or composition as the sole mean of feature extension.
Considering the complexity of the StrTokenizer class, I do not think
that the earlier concern that VariableFormatter+VariableResolver as too
framework-like is really valid.
The interface VariableResolver could be made to live in the
VariableFormatter class we *really* think we need to "hide" this
feature.
If Oliver is up for it and the list does not say "no, no, because...",
I'd like to see a patch to the CVS code that makes VariableFormatter use
a VariableResolver with an canned implementation for Maps.
Gary
I prefer the VariableResolver approach, too. So if nobody objects, I
will create a patch, which re-introduces this interface (as an inner
class) and makes all methods static. (With this approach there is no
need for creating instances of VariableFormatter, right?)
Don't know how much time I have in the next days, so this might take
some days.
Oliver
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
