commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [lang] Converters
Date Thu, 21 Nov 2002 21:36:28 GMT

Stephen Colebourne wrote:
> I agree that something should go in [lang].
> 
> My proposal is that [lang] contains a 'convertor' subpackage that contains a
> factory to obtain a convertor, and implementations for String,
> Integer,(...Number), Date, Enum.  ie. the basic types. Once this is settled,
> additional types can be considered.
> Stephen

Look at Avalon Excalibur Converter, there is already lots of useful 
code, maybe it can be moved in lang, give it a view.

http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/converter/src/java/org/apache/excalibur/converter/lib/

> ----- Original Message -----
> From: "Jeff Varszegi" <jvarszegi@yahoo.com>
> 
>>My Yahoo mail just burped and I don't think it sent my message, but I was
> 
> attempting to email you
> 
>>a reminder about this.  I don't think we should let it go by the wayside.
>>
>>Jeff
>>
>>--- Ola Berg <ola.berg@ports.se> wrote:
>>
>>>>I would prefer participation in NEW project [converter].
>>>>[lang] is used only for general purpose functionality (if I understand
>>>>correctly).
>>>>In such case it would be possible to put some specific conversion
>>>>functionality. Not only for simple types.
>>>
>>>Wouldn't it be better if the base mechanisms for converter was in lang,
>>
> together with
> 
>>>conversions for simple types? The specific conversions belong IMO not in
>>
> a converter package
> 
>>>covering anything from Date to ImaginaryNumber to ResultSet to Money),
>>
> but in the different
> 
>>>specific packages where they are actually needed. A converter package
>>
> containing specific
> 
>>>conversions for many sorts of types would be too broad in scope.
>>>
>>>Instead, the converter mechanism in itself would be really lightweight,
>>
> and you only need a
> 
>>>dependency to lang (which you probably want anyway, given lang's general
>>
> usefulness and small
> 
>>>footprint).
>>>
>>>Another argument: If converter wasn't in lang, we would create cross
>>
> dependencies, since chances
> 
>>>are that lang can benefit from the basic conversion mechanisms, and that
>>
> converter would benefit
> 
>>>from lang (and needs to be dependent upon lang if the converter is a
>>
> variant of Transformation
> 
>>>which is a variant of Closure/Command/Whatever).
>>>
>>>Basic conversion could live happily in lang together with basic
>>
> Predicate logic, other kinds of
> 
>>>transformations etc. Conversion is such a basic pattern.
>>>
>>>/O
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> 
>>>For additional commands, e-mail:
>>
> <mailto:commons-dev-help@jakarta.apache.org>
> 
>>
>>__________________________________________________
>>Do you Yahoo!?
>>Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
>>http://mailplus.yahoo.com
>>
>>--
>>To unsubscribe, e-mail:
> 
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> 
>>For additional commands, e-mail:
> 
> <mailto:commons-dev-help@jakarta.apache.org>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 
> 

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message