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)
Message-ID: <42CF9B0A.3040507@t-online.de>
Date: Sat, 09 Jul 2005 11:38:18 +0200
From: Oliver Heger <oliver.heger@t-online.de>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [lang] text.Interpolation, on to 2.2
References: <B93830D99D595F43996A8899AEDB8F530BD588@ns1018.seagull.nl>
 <42CC6501.6090907@btopenworld.com>
In-Reply-To: <42CC6501.6090907@btopenworld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Some comments inline...

Stephen Colebourne wrote:

> 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 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.
>
>
> 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[])

Okay, to remain consistency this point sounds reasonable. If 
VariableFormatter is reworked to operate on a char[], StrTokenizer will 
certainly be useful. I think, it shouldn't be a problem to implement the 
Matcher interface to locate variables in the source string. But I will 
have to study the StrTokenizer class whether it is possible to extract 
the variables' names once they have been detected.

>
> b) we have lost the ability to have multiple substitutions

I don't understand what you mean with this point.

>
> c) we have added a complex escaping mechanism

That's true, escaping increases complexity. I think we will have to find 
a consense how far we want to go in this area. If you are in control 
over the input for VariableFormatter, escaping might not be an issue 
because you can choose variable delimiters that do not conflict with the 
output you want to generate. But if this is not the case, the use case 
of escaping variables will sooner or later come in naturally.

>
> d) we don't have a replaceOnce() method

This could be realized by passing a noRecursive flag to the main 
substitution method; if this flag is set, no recursive calls will be made.

>
> I would hope that we could have a static method, that is passed all 
> the state, and performs all the work. That way it can be called from 
> StrBuilder in the most efficient way. And StrTokenizer should be 
> rewritten like this too.

This is a good point. The main replace method could be implemented as a 
static method, but we would then lose the possibility of overloading the 
resolveVariable() method to extend the provided functionality. So in 
this case I would prefer to have a VariableResolver interface (instead 
of a plain map), which will support customization more easily.

>
> Stephen
>
Oliver

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