> Gary Gregory wrote:
> > How about this as a compromise (thinking aloud):
> >
> > The (currently imaginary) class VariableFormat holds a Map and
defines a
> > method VariableFormat#resolve(String name).
> >
> > [configuration] can subclass the class and override the
> > VariableFormat#resolve(String name) to provide its own logic. This
would
> > allow for the resolve by delegation scenario.
> >
> > You would "normally" front-load a VariableFormat with a Map.
>
> I'm in two minds about this.
>
> This design is neat, and definitely fits the [lang] scope question (so
> long as StrBuilder can use it directly without copying the char[])
>
> However, it has to be said that if VariableResolver is the only
> interface we are talking about, then it is little different to
> StrTokenizer, so could be considered OK.
>
> Maybe this is a sign that StrTokenizer is too complex? I do think that
> we should have a consistent design between StrTokenizer and
> VariableFormat though.
>
> (could VariableFormat be called StrFormatter to fit with the rest of
the
> classes in the package?).
Hm, interesting, allow me to ramble:
What I like about the *Format name is that it relates it to the
java.text.*Format classes, specifically to the MessageFormat class. From
the MessageFormat javadoc:
"MessageFormat provides a means to produce concatenated messages in
language-neutral way."
Our new lang formatter is pretty much like the JRE class in *intent*
(javadoc above), the main difference is that MessageFormat works on
template strings that use the "{indexNumber}" notation, as opposed to
our class which uses the "${variableName}" notation.
So the question I think is: Do we want to provide a MessageFormat
subclass, say "VariableMessageFormat" which works off a Map, etc?
If we do not, then I'd say it is better not to pick a *Format class
name, to make it clear that our class does not work in the java.text
f/w.
I'm not crazy about having all the .text class names starting with "Str"
unless there is a clear reason to do so. The most important feature of
the new class is that it uses /names/ to lookup values in a /Map/ of
some kind.
IMO, the feature should be reflected in the class name, which
"StrFormatter" does not (for me ;-). Based on the name, you cannot tell
the difference b/w StrFormatter and MessageFormat.
Gary
>
> Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
