commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsoftware.com>
Subject RE: [lang] text.Interpolation, on to 2.2
Date Mon, 18 Jul 2005 21:30:34 GMT
> From: Oliver Heger [mailto:oliver.heger@t-online.de]
> Sent: Sunday, July 17, 2005 12:11 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text.Interpolation, on to 2.2
> 
> Hello Gary,
> 
> the current state of VariableFormatter is fine with me, it allows me
> everything to do I need for [configuration].
> 
> I think the problem will be to satisfy other needs mentioned by others
> in this thread (e.g. operating on a char[], a static interpolation
> method that works without creating an instance). But these points are
> less important for me.
> 
> Oliver


Oliver: Ok, good new.

All:

(1) operating on a char[]

I recall seeing a mention of this earlier but I cannot recall the
driving force for it. Could it be done in a subsequent release or at
least once we are all happy with the String version? We could the double
up with char[] version of the String APIs. Not my favorite but if it
really needed, it is.

(2) static interpolation method that works without creating an instance.

This is also not important to me but I am open to chatting about it.

(3) I would like to remove the two other classes. I'll propose that in
another message to make it more visible when we are more settled with
VariableFormatter WRT 1 and 2 above.

Thanks,
Gary

> 
> Gary Gregory wrote:
> 
> >Hello VariableFormatters:
> >
> >I've retro-fitted the VariableResolver interface into the
> >VariableFormatter class and provided a Map-backed VariableResolver
> >implementation. I did not change everything to statics.
> >
> >I think (and hope) this approach provides an API to address the most
> >common cases (Map) with the ability to extend functionality by
> >implementing your own VariableResolver and possibly subclassing.
> >
> >If Oliver and others could see how this looks and feels to them I
would
> >appreciate any and all comments; in particular as to the use for
> >[configuration].
> >
> >Thanks,
> >Gary
> >
> >
> >
> >>-----Original Message-----
> >>From: Oliver Heger [mailto:oliver.heger@t-online.de]
> >>Sent: Sunday, July 10, 2005 11:45 AM
> >>To: Jakarta Commons Developers List
> >>Subject: Re: [lang] text.Interpolation, on to 2.2
> >>
> >>Gary Gregory wrote:
> >>
> >>
> >>
> >>>I would like us to reconsider the use of the VariableResolver
> >>>
> >>>
> >interface
> >
> >
> >>>for VariableFormatter.
> >>>
> >>>It seems that this is a cleaner design that does not force
> >>>
> >>>
> >subclassing
> >
> >
> >>>or composition as the sole mean of feature extension.
> >>>
> >>>Considering the complexity of the StrTokenizer class, I do not
think
> >>>that the earlier concern that VariableFormatter+VariableResolver as
> >>>
> >>>
> >too
> >
> >
> >>>framework-like is really valid.
> >>>
> >>>The interface VariableResolver could be made to live in the
> >>>VariableFormatter class we *really* think we need to "hide" this
> >>>feature.
> >>>
> >>>If Oliver is up for it and the list does not say "no, no,
> >>>
> >>>
> >because...",
> >
> >
> >>>I'd like to see a patch to the CVS code that makes
VariableFormatter
> >>>
> >>>
> >use
> >
> >
> >>>a VariableResolver with an canned implementation for Maps.
> >>>
> >>>Gary
> >>>
> >>>
> >>>
> >>>
> >>I prefer the VariableResolver approach, too. So if nobody objects, I
> >>will create a patch, which re-introduces this interface (as an inner
> >>class) and makes all methods static. (With this approach there is no
> >>need for creating instances of VariableFormatter, right?)
> >>
> >>Don't know how much time I have in the next days, so this might take
> >>some days.
> >>
> >>Oliver
> >>
> >><snip/>
> >>
> >>
>
>>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message