commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsoftware.com>
Subject RE: [lang] text.Interpolation, on to 2.2
Date Wed, 06 Jul 2005 20:30:04 GMT
> From: Simon Kitching [mailto:skitching@apache.org]
> 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.
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.

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
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".

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

> 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 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.
This
> 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
feature
> is a very nice addition.

Yes, I like that.

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

Well, should we go back to the interface approach?

Gary

> 
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message