Gary Gregory wrote:
-----Original Message-----
From: Oliver Heger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 29, 2005 11:32 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] text.Interpolation, on to 2.2
Gary Gregory wrote:
Oliver (or anyone else), would you be willing to take a first cut at
porting your patch in the Bugzilla ticket referred to earlier to
this
current scheme?
We could then put it in CVS with unit tests and see how it feels to
all
of us once in code form.
Gary
Okay, I can do this. I will get to it probably at the weekend (which
will leave you some time to find a consense for the class name ;-)
Oh, one question remains: The interpolation method in the Bugzilla
ticket operates on Objects rather than Strings. This means, if the
source for interpolation contains only a single variable reference,
the
return value will be the value of this variable, which can be of
arbitrary type. If the source contains multiple variables and/or
static
text, the return value will always be a String with a concatenation of
all these elements.
I think, the most common use case of the class will certainly be
string
based interpolation, so the object handling stuff might be
unnecessary.
On the other hand, if a result object has been calculated, it is
trivial
to convert this into a String by calling its toString() method. The
opposite (converting a String result into a different type) is more
problematic.
What do you think?
When I know that I am always dealing with Strings, it is a bit annoying
to have call toString() on each result. If you really want to keep the
Object version, which seems OK for advanced uses like [configuration],
what about having an "Object resolveObject()" and "String
resolveString()" high level APIs so I can say:
// Uses defaults: ${ and }
VariableFormatter.resolveString(aString, aMap);
VariableFormatter.resolveObject(aString, aMap);
// and maybe even, where the defaults are ${, } and
System.getProperties()
VariableFormatter.resolveString(aString);
// ?
I do not want [configuration] to loose the Object feature *if* it needs
it but I do not want to deal with Object APIs when I know I am dealing
with Strings and we are after all in a .text package.
Hope this helps,
Gary
Yes, the base method returns an Object, and there are several
convenience methods that cast this result to a String. This is what I
had in mind, too.
Thanks,
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
