> -----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
>
> Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
