commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@t-online.de>
Subject Re: [lang] text.Interpolation, on to 2.2
Date Sun, 17 Jul 2005 19:11:15 GMT
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

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


Mime
View raw message