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 Fri, 08 Jul 2005 20:12:33 GMT
> -----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
> 
> 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?
> 
> 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:
> 
> 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[])
> 
> 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


Mime
View raw message