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[])
b) we have lost the ability to have multiple substitutions
c) we have added a complex escaping mechanism
d) we don't have a replaceOnce() method
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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
