Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lang] text.Interpolation, on to 2.2
Date: Wed, 6 Jul 2005 16:30:04 -0400
Message-ID: <B93830D99D595F43996A8899AEDB8F530BD588@ns1018.seagull.nl>
Thread-Topic: [lang] text.Interpolation, on to 2.2
Thread-Index: AcWB5E8ctQejwp0MTfe2BB3t9XGO2QAgzS2A
From: "Gary Gregory" <ggregory@seagullsoftware.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>,
	<skitching@apache.org>

> 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
>=20
> On Wed, 2005-06-29 at 20:24 -0400, Gary Gregory wrote:
>=20
> > 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.
>=20
> 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.

>=20
> 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

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


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