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: Fri, 8 Jul 2005 16:12:33 -0400
Message-ID: <B93830D99D595F43996A8899AEDB8F530BD629@ns1018.seagull.nl>
Thread-Topic: [lang] text.Interpolation, on to 2.2
Thread-Index: AcWCgAHuIcVgw6eIRoip6FlDpAVcAwBeCW1g
From: "Gary Gregory" <ggregory@seagullsoftware.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Wednesday, July 06, 2005 4:11 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text.Interpolation, on to 2.2
>=20
> Gary Gregory wrote:
> >>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?
>=20
> The constrast is with the StrTokenizer class. That alread has an
> interface, and various implementations of the interface. Thus an
> interface for this class is not inapropriate.

I did like the interface approach, I'll take a look at putting it back
in to see how that feels.

>
> I was hoping that there might have been some way to take the
> StrTokenizer interface and make it top level and reuse it in all the
> classes in the text package. Perhaps for locating the delimiters in
> VariableFormatter. But I'm not sure that idea works.

I like the idea of eating our own dog food but I do not know how
practical or easy VariableFormatter can be made to reuses a
StrTokenizer. Perhaps Oliver can opine on this.

> Considering the current VariableFormatter class:
>=20
> a) we don't have the ability to call it directly from StrBuilder
without
> copying the char array to a String. (VariableFormatter needs rewriting
> to operate on a char[])
>=20
> b) we have lost the ability to have multiple substitutions

What do you mean here?

Gary


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