Hello Gary,

the current state of VariableFormatter is fine with me, it allows me everything to do I need for [configuration].

I think the problem will be to satisfy other needs mentioned by others in this thread (e.g. operating on a char[], a static interpolation method that works without creating an instance). But these points are less important for me.

Oliver

Gary Gregory wrote:

Hello VariableFormatters:

I've retro-fitted the VariableResolver interface into the
VariableFormatter class and provided a Map-backed VariableResolver
implementation. I did not change everything to statics.
I think (and hope) this approach provides an API to address the most
common cases (Map) with the ability to extend functionality by
implementing your own VariableResolver and possibly subclassing.
If Oliver and others could see how this looks and feels to them I would
appreciate any and all comments; in particular as to the use for
[configuration].

Thanks,
Gary

-----Original Message-----
From: Oliver Heger [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 10, 2005 11:45 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] text.Interpolation, on to 2.2

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]



---------------------------------------------------------------------
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]

Reply via email to