Gary Gregory wrote:
At a minimum, I'd like to see MapVariableResolver packge scoped.

Looking at the message thread:
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg78697.html
It seems that another proposal being discussed back in April was to make
some classes /easier/ to reuse and extend for the more advanced users by
making them come out of inner, which would also mean keeping them
public.

The problem here is that once we publish the API thats it, we can't unpublish it. MapVariableResolver seems like an internal class that we create for our own needs. All the constructors allow for a Map to be passed in, so the users of MapVariableResolver will be very much edge case users.


However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.

Gary Gregory wrote:
The challenge to me here is that I've heard some folks says they do not
want [lang] to become too framework-like. I am wondering if making
VariableResolver more generic would go in that direction. The nice thing
I see about the way it is now is that the solution is on making the
variable resolver pluggable and nothing more. Which is a draw back if
that interface is really /that great/.

The question is whether we can see a [lang] use case for using StrLookup other than in VariableFormatter.


Oliver Heger wrote:
> Fine with me, but could the return value of lookup be Object instead
> of String? Especially if you want to use this interface in other
 areas, you might need more freedom. If only String processing needs
> to be performed, the returned Object can be transformed to a String by
> calling toString().

But what kind of object are you expectng to be returned here (other than a String)?

A similar question applies to the replaceObject() method which appears to have very odd semantics as you can't rely on the return value being of any specific type. What Objects are you expecting to work with?

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to