commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <>
Subject RE: [lang] text.Interpolation, on to 2.2
Date Wed, 06 Jul 2005 20:30:04 GMT
> From: Simon Kitching []
> Sent: Tuesday, July 05, 2005 9:38 PM
> To: Jakarta Commons Developers List
> Subject: RE: [lang] text.Interpolation, on to 2.2
> 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.
> > 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
> > 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
> > unless there is a clear reason to do so. The most important feature
> > 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
> > the difference b/w StrFormatter and MessageFormat.
> I am concerned about the parallels being drawn between MessageFormat
> (proposed) VariableFormat. While they are both about combining
> with variables, they actually work in opposite ways. MessageFormat is
> based on defining a template "My {0} is {1}.", then evaulating this
> different values of {0} and {1}. The (proposed) VariableFormat is
> 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.

My idea (see [POLL] email and express yourself ;-) would be to keep and
rename VariableFormat and remove the two other classes: Interpolation
and MappedMessageFormat.

> 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
> And it doesn't seem that it can (or should) do this, so I would like
> see whatever solution is agreed on avoid the name "Format".

Yes, I will rename VariableFormat to... VariableFormatter for now.

> I am also concerned about the complexity of the VariableFormat API;
> class has something like a dozen non-private methods. I would be very
> keen to see it split into an interface + implementation so people
> provide alternative implementations (like java.text.Format is the base
> for multiple formatters).

The original code from Oliver did have an interface to resolve
variables. The discussion on this list had some in favor of a simpler
solution: just one class that can be subclassed. In particular, some had
the impression that Oliver's original code was too framework-like. The
current one class solution still solves Oliver's requirements for
[configuration]. I am open to going back to Oliver's use of an interface
to resolve variable, which I thought was really nice.

> The VariableFormat class has also done away with the ability to have
> multiple sources of data which was present in MappedMessageFormat.
> functionality is not critical, but it's nice.

A subclass can resolve variables as it sees fit. The issue in my mind,
is that a subclass creates tight coupling, while Oliver's original
VariableResolver interface created a more flexible solution, albeit,
more "framework-like", which some folks disliked.

> On the other hand the repeated substitution with cycle detection
> is a very nice addition.

Yes, I like that.

> The source of values for the VariableFormat class is only allowed to
> a Map. I'm not sure if people will want other types of data sources.
> the resolveVariable method does allow customisation via subclassing
> the fact that the "default" source is a map is very obviously exposed
> via the class API.

Well, should we go back to the interface approach?


> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message