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 Thu, 30 Jun 2005 18:21:11 GMT
Gary Gregory wrote:

>>-----Original Message-----
>>From: Oliver Heger [mailto:hegero@med.uni-marburg.de]
>>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
>
>  
>
Yes, the base method returns an Object, and there are several 
convenience methods that cast this result to a String. This is what I 
had in mind, too.

Thanks,
Oliver

---------------------------------------------------------------------
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