You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/11/21 22:11:29 UTC
Re: [lang] Converters
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
----- Original Message -----
From: "Jeff Varszegi" <jv...@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 <ol...@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:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Converters
Posted by Ola Berg <ol...@ports.se>.
> 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
Agree. But why 'convertor'? Why not 'converter' or 'convert'?
/O
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Converters
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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" <jv...@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 <ol...@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:
>>
> <ma...@jakarta.apache.org>
>
>>>For additional commands, e-mail:
>>
> <ma...@jakarta.apache.org>
>
>>
>>__________________________________________________
>>Do you Yahoo!?
>>Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
>>http://mailplus.yahoo.com
>>
>>--
>>To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>