On Wed, 2005-06-29 at 20:24 -0400, Gary Gregory wrote:
> 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.
I am concerned about the parallels being drawn between MessageFormat and
(proposed) VariableFormat. While they are both about combining messages
with variables, they actually work in opposite ways. MessageFormat is
based on defining a template "My {0} is {1}.", then evaulating this for
different values of {0} and {1}. The (proposed) VariableFormat is based
on defining a source of variable info (Map), then evaulating different
template strings against that map. I think the current VariableFormat
approach is the right approach for mapped data but this difference
implies that care should be taken when drawing any parallels between
these classes.
I think this is what Gary meant above; that if this class cannot be
implemented as a subclass of java.text.MessageFormat (or at least a
subclass of java.text.Format) then it shouldn't have Format in the name.
And it doesn't seem that it can (or should) do this, so I would like to
see whatever solution is agreed on avoid the name "Format".
I am also concerned about the complexity of the VariableFormat API; the
class has something like a dozen non-private methods. I would be very
keen to see it split into an interface + implementation so people could
provide alternative implementations (like java.text.Format is the base
for multiple formatters).
The VariableFormat class has also done away with the ability to have
multiple sources of data which was present in MappedMessageFormat. This
functionality is not critical, but it's nice.
On the other hand the repeated substitution with cycle detection feature
is a very nice addition.
The source of values for the VariableFormat class is only allowed to be
a Map. I'm not sure if people will want other types of data sources. Yes
the resolveVariable method does allow customisation via subclassing but
the fact that the "default" source is a map is very obviously exposed
via the class API.
All these comments are a little rushed; I'm trying to juggle several
things at once at the moment so sorry for that. I'll try to spend a
little more time on this soon.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
