Emmanuel Bourg wrote:
Gary Gregory wrote:
- For [config]: Provide an Interpolation feature that it can build on.
The [config] project, please correct me if I am off, must have a way to
plug-in how to look stuff up, hence the nice and simple VariableResolver
interface, which could be surfaced as:
String s = XXX.resolveAll(source, ..., aVariableResolver);
There is also a [config] need for multiple VariableResolvers it seems,
which means that the API can take a Map of VariableResolver or that the
client simply calls the API until all resolve calls worked. But how do
you determine that an API call resolved everything? If one cannot
(Oliver?), then we have to provide a resolveInAll(String, Map) (or other
name)?
And what about some kind of chained VariableResolver ? A resolver that
will check several resolvers or use a specific resolver depending on
the key ? Thus there is no need to have several resolveAll methods and
the actual strategy is delegated to the resolver.
Emmanuel Bourg
Yes, this is exactly what I meant by
"Then I could pack the logic I had before in my Interpolation class
(support for different variable resolvers, default variable resolver
etc.) into a special implementation of this interface."
The idea is to somehow associate variables with a concrete resolver. As an
example, an input could look like:
"File ${x:fileName} was stored in ${sys:user.home} at ${e:now}"
Then there would be a composite or chained variable resolver that would know,
which of its child resolver to use for the different variables. So the API in
[lang] can remain simple and complex logic can be put in specific
implementations of the VariableResolver interface (which would live in other
projects).
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
