You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Carman <ja...@carmanconsulting.com> on 2011/11/04 03:19:57 UTC
[convert] API Discussion...
I was taking a look at the [convert] component because I have done
some work lately on some handy conversion classes. I'm struggling to
understand why you'd need the getSourceClass() and getTargetClass()
methods if you're using generics.
Also, I've got a class that looks like this:
public class ConverterChain<S,T> implements Converter<S,T>
{
public static <S> ConverterChain<S,S> from(Class<S> sourceType);
public <N> ConverterChain<S,N> append(Converter<T,N> converter);
...
}
I'd like to contribute it, but in my library, I don't have all of
those references to the class objects (source/target). I might check
it in without the source/target stuff implemented.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by James Carman <ja...@carmanconsulting.com>.
Sounds interesting. I will try to take a deeper dive look at it this weekend
On Nov 4, 2011 7:19 AM, "Adrian Crum" <ad...@sandglass-software.com>
wrote:
> It's a lot more dynamic than that. The factory is "smart" - it creates and
> registers converters on-the-fly as it is used.
>
> -Adrian
>
> On 11/4/2011 11:17 AM, James Carman wrote:
>
>> I would think that the source and target would be a part of the
>> registration process and not a member of each individual converter
>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
>> software.com <ad...@sandglass-software.com>>
>> wrote:
>>
>> The source and target classes are used by the Converter.canConvert
>>> method.
>>> The Converter.canConvert method is used by the Converter factory to find
>>> the correct converter. The reason parameterized types are not used in
>>> this
>>> scenario is so you can create converters that handle entire class
>>> hierarchies. If you can think of a way to replace the Class references
>>> with
>>> parameters, that would be great. Submit a patch and I will look it over.
>>>
>>> You could submit a patch for your partially-completed ConverterChain
>>> class
>>> and maybe someone else will complete it.
>>>
>>> -Adrian
>>>
>>>
>>> On 11/4/2011 2:19 AM, James Carman wrote:
>>>
>>> I was taking a look at the [convert] component because I have done
>>>> some work lately on some handy conversion classes. I'm struggling to
>>>> understand why you'd need the getSourceClass() and getTargetClass()
>>>> methods if you're using generics.
>>>>
>>>>
>>>> Also, I've got a class that looks like this:
>>>>
>>>> public class ConverterChain<S,T> implements Converter<S,T>
>>>> {
>>>> public static<S> ConverterChain<S,S> from(Class<S> sourceType);
>>>> public<N> ConverterChain<S,N> append(Converter<T,N> converter);
>>>> ...
>>>> }
>>>>
>>>> I'd like to contribute it, but in my library, I don't have all of
>>>> those references to the class objects (source/target). I might check
>>>> it in without the source/target stuff implemented.
>>>>
>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>> <de...@commons.apache.org>
>>>> >
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>> <de...@commons.apache.org>
>>> >
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [convert] API Discussion...
Posted by Adrian Crum <ad...@sandglass-software.com>.
It's a lot more dynamic than that. The factory is "smart" - it creates
and registers converters on-the-fly as it is used.
-Adrian
On 11/4/2011 11:17 AM, James Carman wrote:
> I would think that the source and target would be a part of the
> registration process and not a member of each individual converter
> On Nov 4, 2011 5:55 AM, "Adrian Crum"<ad...@sandglass-software.com>
> wrote:
>
>> The source and target classes are used by the Converter.canConvert method.
>> The Converter.canConvert method is used by the Converter factory to find
>> the correct converter. The reason parameterized types are not used in this
>> scenario is so you can create converters that handle entire class
>> hierarchies. If you can think of a way to replace the Class references with
>> parameters, that would be great. Submit a patch and I will look it over.
>>
>> You could submit a patch for your partially-completed ConverterChain class
>> and maybe someone else will complete it.
>>
>> -Adrian
>>
>>
>> On 11/4/2011 2:19 AM, James Carman wrote:
>>
>>> I was taking a look at the [convert] component because I have done
>>> some work lately on some handy conversion classes. I'm struggling to
>>> understand why you'd need the getSourceClass() and getTargetClass()
>>> methods if you're using generics.
>>>
>>>
>>> Also, I've got a class that looks like this:
>>>
>>> public class ConverterChain<S,T> implements Converter<S,T>
>>> {
>>> public static<S> ConverterChain<S,S> from(Class<S> sourceType);
>>> public<N> ConverterChain<S,N> append(Converter<T,N> converter);
>>> ...
>>> }
>>>
>>> I'd like to contribute it, but in my library, I don't have all of
>>> those references to the class objects (source/target). I might check
>>> it in without the source/target stuff implemented.
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by James Carman <ja...@carmanconsulting.com>.
I would think that the source and target would be a part of the
registration process and not a member of each individual converter
On Nov 4, 2011 5:55 AM, "Adrian Crum" <ad...@sandglass-software.com>
wrote:
> The source and target classes are used by the Converter.canConvert method.
> The Converter.canConvert method is used by the Converter factory to find
> the correct converter. The reason parameterized types are not used in this
> scenario is so you can create converters that handle entire class
> hierarchies. If you can think of a way to replace the Class references with
> parameters, that would be great. Submit a patch and I will look it over.
>
> You could submit a patch for your partially-completed ConverterChain class
> and maybe someone else will complete it.
>
> -Adrian
>
>
> On 11/4/2011 2:19 AM, James Carman wrote:
>
>> I was taking a look at the [convert] component because I have done
>> some work lately on some handy conversion classes. I'm struggling to
>> understand why you'd need the getSourceClass() and getTargetClass()
>> methods if you're using generics.
>>
>>
>> Also, I've got a class that looks like this:
>>
>> public class ConverterChain<S,T> implements Converter<S,T>
>> {
>> public static<S> ConverterChain<S,S> from(Class<S> sourceType);
>> public<N> ConverterChain<S,N> append(Converter<T,N> converter);
>> ...
>> }
>>
>> I'd like to contribute it, but in my library, I don't have all of
>> those references to the class objects (source/target). I might check
>> it in without the source/target stuff implemented.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [convert] API Discussion...
Posted by Simone Tripodi <si...@apache.org>.
Yes, there is space for a lot of improvements, in both therms of APIs
and performances! :)
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Nov 5, 2011 at 4:27 PM, James Carman <ja...@carmanconsulting.com> wrote:
> Well, with that idea, it got me interested in Meiyo. So, now I'm
> playing around in a DSL branch trying to improve the API. It seems
> too verbose to me at the moment. :)
>
>
> On Sat, Nov 5, 2011 at 11:21 AM, Simone Tripodi
> <si...@apache.org> wrote:
>> Hi James!
>> I like the idea, the concept reminds me how TestNG's DataProvider and
>> GoogleGuice Providers.
>> Looking forward to see it in action!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Sat, Nov 5, 2011 at 3:48 PM, James Carman <ja...@carmanconsulting.com> wrote:
>>> What if we introduce a @Converter annotation and any method that is
>>> annotated with this annotation is automatically registered as a
>>> converter? It's similar to what I've done in Metastopheles
>>> (http://metastopheles.sourceforge.net/).
>>>
>>> On Fri, Nov 4, 2011 at 8:15 AM, Adrian Crum
>>> <ad...@sandglass-software.com> wrote:
>>>> Agreed. Please don't mis-interpret my replies - I'm not trying to "own" the
>>>> sandbox, I just want everyone to have a chance to play in it.
>>>>
>>>> The recent interest in Convert is great - I hope its popularity and
>>>> usefulness grows. I'm truly looking forward to more people getting involved.
>>>>
>>>> The current code base started out as a work I authored for the Apache Open
>>>> For Business Project (OFBiz). The converter framework was used for OFBiz's
>>>> scripting language. My initial work was built out and improved upon by an
>>>> excellent team of developers. When the converter framework was fairly
>>>> complete, someone suggested that OFBiz "spin off" the converter framework to
>>>> a separate library - so I brought it here to Commons.
>>>>
>>>> The code you see today is currently being used in an enterprise-class open
>>>> source ERP application. It is scalable and thread-safe.
>>>>
>>>> Commons Convert has not been "fed back" to the OFBiz project yet because it
>>>> is still in the sandbox. Until a decent sized community grows around it, the
>>>> OFBiz community will not be willing to switch over to it. I hope to see that
>>>> switch happen someday.
>>>>
>>>> -Adrian
>>>>
>>>> On 11/4/2011 11:33 AM, James Carman wrote:
>>>>>
>>>>> A branch would work just fine for that situation. Also, let's keep in mind
>>>>> that this component is in the sandbox
>>>>> On Nov 4, 2011 7:28 AM, "Adrian Crum"<ad...@sandglass-software.com>
>>>>> wrote:
>>>>>
>>>>>> Not so that someone else can commit them, so that others can review them
>>>>>> and comment on them.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 11/4/2011 11:25 AM, James Carman wrote:
>>>>>>
>>>>>>> If need be, I would just create a branch for my work. It would be silly
>>>>>>> for me to submit patches so that someone else would commit them
>>>>>>> On Nov 4, 2011 7:20 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>>>>> software.com<ad...@sandglass-software.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> From my perspective, it would be preferable to keep the community
>>>>>>>>
>>>>>>>> involved
>>>>>>>> in the design decisions.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 11/4/2011 11:15 AM, James Carman wrote:
>>>>>>>>
>>>>>>>> I don't have to submit a patch. I am a commons committer
>>>>>>>>>
>>>>>>>>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>>>>>>>
>>>>>>>>> software.com<ad...@sandglass-software.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> The source and target classes are used by the Converter.canConvert
>>>>>>>>>
>>>>>>>>>> method.
>>>>>>>>>> The Converter.canConvert method is used by the Converter factory to
>>>>>>>>>> find
>>>>>>>>>> the correct converter. The reason parameterized types are not used in
>>>>>>>>>> this
>>>>>>>>>> scenario is so you can create converters that handle entire class
>>>>>>>>>> hierarchies. If you can think of a way to replace the Class
>>>>>>>>>> references
>>>>>>>>>> with
>>>>>>>>>> parameters, that would be great. Submit a patch and I will look it
>>>>>>>>>> over.
>>>>>>>>>>
>>>>>>>>>> You could submit a patch for your partially-completed ConverterChain
>>>>>>>>>> class
>>>>>>>>>> and maybe someone else will complete it.
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/4/2011 2:19 AM, James Carman wrote:
>>>>>>>>>>
>>>>>>>>>> I was taking a look at the [convert] component because I have done
>>>>>>>>>>
>>>>>>>>>>> some work lately on some handy conversion classes. I'm struggling
>>>>>>>>>>> to
>>>>>>>>>>> understand why you'd need the getSourceClass() and getTargetClass()
>>>>>>>>>>> methods if you're using generics.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Also, I've got a class that looks like this:
>>>>>>>>>>>
>>>>>>>>>>> public class ConverterChain<S,T> implements Converter<S,T>
>>>>>>>>>>> {
>>>>>>>>>>> public static<S> ConverterChain<S,S> from(Class<S>
>>>>>>>>>>> sourceType);
>>>>>>>>>>> public<N> ConverterChain<S,N> append(Converter<T,N>
>>>>>>>>>>> converter);
>>>>>>>>>>> ...
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> I'd like to contribute it, but in my library, I don't have all of
>>>>>>>>>>> those references to the class objects (source/target). I might
>>>>>>>>>>> check
>>>>>>>>>>> it in without the source/target stuff implemented.
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>>>>> --**---------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>>>>>> http://apache.org**>
>>>>>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>>>>>>
>>>>>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>>>>>
>>>>>>>>>> --**---------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>>>>> http://apache.org**>
>>>>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>>>>>
>>>>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------****----------------------------**
>>>>>>>>
>>>>>>>> --**---------
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>> dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>>>>>>
>>>>>>>> <de...@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> ------------------------------**------------------------------**---------
>>>>>> To unsubscribe, e-mail:
>>>>>> dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by James Carman <ja...@carmanconsulting.com>.
Well, with that idea, it got me interested in Meiyo. So, now I'm
playing around in a DSL branch trying to improve the API. It seems
too verbose to me at the moment. :)
On Sat, Nov 5, 2011 at 11:21 AM, Simone Tripodi
<si...@apache.org> wrote:
> Hi James!
> I like the idea, the concept reminds me how TestNG's DataProvider and
> GoogleGuice Providers.
> Looking forward to see it in action!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Nov 5, 2011 at 3:48 PM, James Carman <ja...@carmanconsulting.com> wrote:
>> What if we introduce a @Converter annotation and any method that is
>> annotated with this annotation is automatically registered as a
>> converter? It's similar to what I've done in Metastopheles
>> (http://metastopheles.sourceforge.net/).
>>
>> On Fri, Nov 4, 2011 at 8:15 AM, Adrian Crum
>> <ad...@sandglass-software.com> wrote:
>>> Agreed. Please don't mis-interpret my replies - I'm not trying to "own" the
>>> sandbox, I just want everyone to have a chance to play in it.
>>>
>>> The recent interest in Convert is great - I hope its popularity and
>>> usefulness grows. I'm truly looking forward to more people getting involved.
>>>
>>> The current code base started out as a work I authored for the Apache Open
>>> For Business Project (OFBiz). The converter framework was used for OFBiz's
>>> scripting language. My initial work was built out and improved upon by an
>>> excellent team of developers. When the converter framework was fairly
>>> complete, someone suggested that OFBiz "spin off" the converter framework to
>>> a separate library - so I brought it here to Commons.
>>>
>>> The code you see today is currently being used in an enterprise-class open
>>> source ERP application. It is scalable and thread-safe.
>>>
>>> Commons Convert has not been "fed back" to the OFBiz project yet because it
>>> is still in the sandbox. Until a decent sized community grows around it, the
>>> OFBiz community will not be willing to switch over to it. I hope to see that
>>> switch happen someday.
>>>
>>> -Adrian
>>>
>>> On 11/4/2011 11:33 AM, James Carman wrote:
>>>>
>>>> A branch would work just fine for that situation. Also, let's keep in mind
>>>> that this component is in the sandbox
>>>> On Nov 4, 2011 7:28 AM, "Adrian Crum"<ad...@sandglass-software.com>
>>>> wrote:
>>>>
>>>>> Not so that someone else can commit them, so that others can review them
>>>>> and comment on them.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 11/4/2011 11:25 AM, James Carman wrote:
>>>>>
>>>>>> If need be, I would just create a branch for my work. It would be silly
>>>>>> for me to submit patches so that someone else would commit them
>>>>>> On Nov 4, 2011 7:20 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>>>> software.com<ad...@sandglass-software.com>>
>>>>>> wrote:
>>>>>>
>>>>>> From my perspective, it would be preferable to keep the community
>>>>>>>
>>>>>>> involved
>>>>>>> in the design decisions.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 11/4/2011 11:15 AM, James Carman wrote:
>>>>>>>
>>>>>>> I don't have to submit a patch. I am a commons committer
>>>>>>>>
>>>>>>>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>>>>>>
>>>>>>>> software.com<ad...@sandglass-software.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> The source and target classes are used by the Converter.canConvert
>>>>>>>>
>>>>>>>>> method.
>>>>>>>>> The Converter.canConvert method is used by the Converter factory to
>>>>>>>>> find
>>>>>>>>> the correct converter. The reason parameterized types are not used in
>>>>>>>>> this
>>>>>>>>> scenario is so you can create converters that handle entire class
>>>>>>>>> hierarchies. If you can think of a way to replace the Class
>>>>>>>>> references
>>>>>>>>> with
>>>>>>>>> parameters, that would be great. Submit a patch and I will look it
>>>>>>>>> over.
>>>>>>>>>
>>>>>>>>> You could submit a patch for your partially-completed ConverterChain
>>>>>>>>> class
>>>>>>>>> and maybe someone else will complete it.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/4/2011 2:19 AM, James Carman wrote:
>>>>>>>>>
>>>>>>>>> I was taking a look at the [convert] component because I have done
>>>>>>>>>
>>>>>>>>>> some work lately on some handy conversion classes. I'm struggling
>>>>>>>>>> to
>>>>>>>>>> understand why you'd need the getSourceClass() and getTargetClass()
>>>>>>>>>> methods if you're using generics.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also, I've got a class that looks like this:
>>>>>>>>>>
>>>>>>>>>> public class ConverterChain<S,T> implements Converter<S,T>
>>>>>>>>>> {
>>>>>>>>>> public static<S> ConverterChain<S,S> from(Class<S>
>>>>>>>>>> sourceType);
>>>>>>>>>> public<N> ConverterChain<S,N> append(Converter<T,N>
>>>>>>>>>> converter);
>>>>>>>>>> ...
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> I'd like to contribute it, but in my library, I don't have all of
>>>>>>>>>> those references to the class objects (source/target). I might
>>>>>>>>>> check
>>>>>>>>>> it in without the source/target stuff implemented.
>>>>>>>>>>
>>>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>>>> --**---------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>>>>> http://apache.org**>
>>>>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>>>>>
>>>>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>>>>
>>>>>>>>> --**---------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>>>> http://apache.org**>
>>>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>>>>
>>>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------****----------------------------**
>>>>>>>
>>>>>>> --**---------
>>>>>>> To unsubscribe, e-mail:
>>>>>>> dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>>>>>
>>>>>>> <de...@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> ------------------------------**------------------------------**---------
>>>>> To unsubscribe, e-mail:
>>>>> dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by Simone Tripodi <si...@apache.org>.
Hi James!
I like the idea, the concept reminds me how TestNG's DataProvider and
GoogleGuice Providers.
Looking forward to see it in action!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Nov 5, 2011 at 3:48 PM, James Carman <ja...@carmanconsulting.com> wrote:
> What if we introduce a @Converter annotation and any method that is
> annotated with this annotation is automatically registered as a
> converter? It's similar to what I've done in Metastopheles
> (http://metastopheles.sourceforge.net/).
>
> On Fri, Nov 4, 2011 at 8:15 AM, Adrian Crum
> <ad...@sandglass-software.com> wrote:
>> Agreed. Please don't mis-interpret my replies - I'm not trying to "own" the
>> sandbox, I just want everyone to have a chance to play in it.
>>
>> The recent interest in Convert is great - I hope its popularity and
>> usefulness grows. I'm truly looking forward to more people getting involved.
>>
>> The current code base started out as a work I authored for the Apache Open
>> For Business Project (OFBiz). The converter framework was used for OFBiz's
>> scripting language. My initial work was built out and improved upon by an
>> excellent team of developers. When the converter framework was fairly
>> complete, someone suggested that OFBiz "spin off" the converter framework to
>> a separate library - so I brought it here to Commons.
>>
>> The code you see today is currently being used in an enterprise-class open
>> source ERP application. It is scalable and thread-safe.
>>
>> Commons Convert has not been "fed back" to the OFBiz project yet because it
>> is still in the sandbox. Until a decent sized community grows around it, the
>> OFBiz community will not be willing to switch over to it. I hope to see that
>> switch happen someday.
>>
>> -Adrian
>>
>> On 11/4/2011 11:33 AM, James Carman wrote:
>>>
>>> A branch would work just fine for that situation. Also, let's keep in mind
>>> that this component is in the sandbox
>>> On Nov 4, 2011 7:28 AM, "Adrian Crum"<ad...@sandglass-software.com>
>>> wrote:
>>>
>>>> Not so that someone else can commit them, so that others can review them
>>>> and comment on them.
>>>>
>>>> -Adrian
>>>>
>>>> On 11/4/2011 11:25 AM, James Carman wrote:
>>>>
>>>>> If need be, I would just create a branch for my work. It would be silly
>>>>> for me to submit patches so that someone else would commit them
>>>>> On Nov 4, 2011 7:20 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>>> software.com<ad...@sandglass-software.com>>
>>>>> wrote:
>>>>>
>>>>> From my perspective, it would be preferable to keep the community
>>>>>>
>>>>>> involved
>>>>>> in the design decisions.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 11/4/2011 11:15 AM, James Carman wrote:
>>>>>>
>>>>>> I don't have to submit a patch. I am a commons committer
>>>>>>>
>>>>>>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>>>>>
>>>>>>> software.com<ad...@sandglass-software.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> The source and target classes are used by the Converter.canConvert
>>>>>>>
>>>>>>>> method.
>>>>>>>> The Converter.canConvert method is used by the Converter factory to
>>>>>>>> find
>>>>>>>> the correct converter. The reason parameterized types are not used in
>>>>>>>> this
>>>>>>>> scenario is so you can create converters that handle entire class
>>>>>>>> hierarchies. If you can think of a way to replace the Class
>>>>>>>> references
>>>>>>>> with
>>>>>>>> parameters, that would be great. Submit a patch and I will look it
>>>>>>>> over.
>>>>>>>>
>>>>>>>> You could submit a patch for your partially-completed ConverterChain
>>>>>>>> class
>>>>>>>> and maybe someone else will complete it.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/4/2011 2:19 AM, James Carman wrote:
>>>>>>>>
>>>>>>>> I was taking a look at the [convert] component because I have done
>>>>>>>>
>>>>>>>>> some work lately on some handy conversion classes. I'm struggling
>>>>>>>>> to
>>>>>>>>> understand why you'd need the getSourceClass() and getTargetClass()
>>>>>>>>> methods if you're using generics.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, I've got a class that looks like this:
>>>>>>>>>
>>>>>>>>> public class ConverterChain<S,T> implements Converter<S,T>
>>>>>>>>> {
>>>>>>>>> public static<S> ConverterChain<S,S> from(Class<S>
>>>>>>>>> sourceType);
>>>>>>>>> public<N> ConverterChain<S,N> append(Converter<T,N>
>>>>>>>>> converter);
>>>>>>>>> ...
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I'd like to contribute it, but in my library, I don't have all of
>>>>>>>>> those references to the class objects (source/target). I might
>>>>>>>>> check
>>>>>>>>> it in without the source/target stuff implemented.
>>>>>>>>>
>>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>>> --**---------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>>>> http://apache.org**>
>>>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>>>>
>>>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>>>
>>>>>>>> --**---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>>> http://apache.org**>
>>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>>>
>>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------****----------------------------**
>>>>>>
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail:
>>>>>> dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>>>>
>>>>>> <de...@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail:
>>>> dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by James Carman <ja...@carmanconsulting.com>.
What if we introduce a @Converter annotation and any method that is
annotated with this annotation is automatically registered as a
converter? It's similar to what I've done in Metastopheles
(http://metastopheles.sourceforge.net/).
On Fri, Nov 4, 2011 at 8:15 AM, Adrian Crum
<ad...@sandglass-software.com> wrote:
> Agreed. Please don't mis-interpret my replies - I'm not trying to "own" the
> sandbox, I just want everyone to have a chance to play in it.
>
> The recent interest in Convert is great - I hope its popularity and
> usefulness grows. I'm truly looking forward to more people getting involved.
>
> The current code base started out as a work I authored for the Apache Open
> For Business Project (OFBiz). The converter framework was used for OFBiz's
> scripting language. My initial work was built out and improved upon by an
> excellent team of developers. When the converter framework was fairly
> complete, someone suggested that OFBiz "spin off" the converter framework to
> a separate library - so I brought it here to Commons.
>
> The code you see today is currently being used in an enterprise-class open
> source ERP application. It is scalable and thread-safe.
>
> Commons Convert has not been "fed back" to the OFBiz project yet because it
> is still in the sandbox. Until a decent sized community grows around it, the
> OFBiz community will not be willing to switch over to it. I hope to see that
> switch happen someday.
>
> -Adrian
>
> On 11/4/2011 11:33 AM, James Carman wrote:
>>
>> A branch would work just fine for that situation. Also, let's keep in mind
>> that this component is in the sandbox
>> On Nov 4, 2011 7:28 AM, "Adrian Crum"<ad...@sandglass-software.com>
>> wrote:
>>
>>> Not so that someone else can commit them, so that others can review them
>>> and comment on them.
>>>
>>> -Adrian
>>>
>>> On 11/4/2011 11:25 AM, James Carman wrote:
>>>
>>>> If need be, I would just create a branch for my work. It would be silly
>>>> for me to submit patches so that someone else would commit them
>>>> On Nov 4, 2011 7:20 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>> software.com<ad...@sandglass-software.com>>
>>>> wrote:
>>>>
>>>> From my perspective, it would be preferable to keep the community
>>>>>
>>>>> involved
>>>>> in the design decisions.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 11/4/2011 11:15 AM, James Carman wrote:
>>>>>
>>>>> I don't have to submit a patch. I am a commons committer
>>>>>>
>>>>>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>>>>
>>>>>> software.com<ad...@sandglass-software.com>
>>>>>> wrote:
>>>>>>
>>>>>> The source and target classes are used by the Converter.canConvert
>>>>>>
>>>>>>> method.
>>>>>>> The Converter.canConvert method is used by the Converter factory to
>>>>>>> find
>>>>>>> the correct converter. The reason parameterized types are not used in
>>>>>>> this
>>>>>>> scenario is so you can create converters that handle entire class
>>>>>>> hierarchies. If you can think of a way to replace the Class
>>>>>>> references
>>>>>>> with
>>>>>>> parameters, that would be great. Submit a patch and I will look it
>>>>>>> over.
>>>>>>>
>>>>>>> You could submit a patch for your partially-completed ConverterChain
>>>>>>> class
>>>>>>> and maybe someone else will complete it.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 11/4/2011 2:19 AM, James Carman wrote:
>>>>>>>
>>>>>>> I was taking a look at the [convert] component because I have done
>>>>>>>
>>>>>>>> some work lately on some handy conversion classes. I'm struggling
>>>>>>>> to
>>>>>>>> understand why you'd need the getSourceClass() and getTargetClass()
>>>>>>>> methods if you're using generics.
>>>>>>>>
>>>>>>>>
>>>>>>>> Also, I've got a class that looks like this:
>>>>>>>>
>>>>>>>> public class ConverterChain<S,T> implements Converter<S,T>
>>>>>>>> {
>>>>>>>> public static<S> ConverterChain<S,S> from(Class<S>
>>>>>>>> sourceType);
>>>>>>>> public<N> ConverterChain<S,N> append(Converter<T,N>
>>>>>>>> converter);
>>>>>>>> ...
>>>>>>>> }
>>>>>>>>
>>>>>>>> I'd like to contribute it, but in my library, I don't have all of
>>>>>>>> those references to the class objects (source/target). I might
>>>>>>>> check
>>>>>>>> it in without the source/target stuff implemented.
>>>>>>>>
>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>> --**---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>>> http://apache.org**>
>>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>>>
>>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>>
>>>>>>> --**---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>> http://apache.org**>
>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>>
>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------****----------------------------**
>>>>>
>>>>> --**---------
>>>>> To unsubscribe, e-mail:
>>>>> dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>>>
>>>>> <de...@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by Simone Tripodi <si...@apache.org>.
I am interested on see Jame's code, a brach would work perfectly for me!
Matt Benson has nice stuff too at his hands, it would be great having
all of them merged in one project. Maybe one day [beanutils] will be
the main [convert] consumer... :)
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Nov 4, 2011 at 1:15 PM, Adrian Crum
<ad...@sandglass-software.com> wrote:
> Agreed. Please don't mis-interpret my replies - I'm not trying to "own" the
> sandbox, I just want everyone to have a chance to play in it.
>
> The recent interest in Convert is great - I hope its popularity and
> usefulness grows. I'm truly looking forward to more people getting involved.
>
> The current code base started out as a work I authored for the Apache Open
> For Business Project (OFBiz). The converter framework was used for OFBiz's
> scripting language. My initial work was built out and improved upon by an
> excellent team of developers. When the converter framework was fairly
> complete, someone suggested that OFBiz "spin off" the converter framework to
> a separate library - so I brought it here to Commons.
>
> The code you see today is currently being used in an enterprise-class open
> source ERP application. It is scalable and thread-safe.
>
> Commons Convert has not been "fed back" to the OFBiz project yet because it
> is still in the sandbox. Until a decent sized community grows around it, the
> OFBiz community will not be willing to switch over to it. I hope to see that
> switch happen someday.
>
> -Adrian
>
> On 11/4/2011 11:33 AM, James Carman wrote:
>>
>> A branch would work just fine for that situation. Also, let's keep in mind
>> that this component is in the sandbox
>> On Nov 4, 2011 7:28 AM, "Adrian Crum"<ad...@sandglass-software.com>
>> wrote:
>>
>>> Not so that someone else can commit them, so that others can review them
>>> and comment on them.
>>>
>>> -Adrian
>>>
>>> On 11/4/2011 11:25 AM, James Carman wrote:
>>>
>>>> If need be, I would just create a branch for my work. It would be silly
>>>> for me to submit patches so that someone else would commit them
>>>> On Nov 4, 2011 7:20 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>> software.com<ad...@sandglass-software.com>>
>>>> wrote:
>>>>
>>>> From my perspective, it would be preferable to keep the community
>>>>>
>>>>> involved
>>>>> in the design decisions.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 11/4/2011 11:15 AM, James Carman wrote:
>>>>>
>>>>> I don't have to submit a patch. I am a commons committer
>>>>>>
>>>>>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>>>>
>>>>>> software.com<ad...@sandglass-software.com>
>>>>>> wrote:
>>>>>>
>>>>>> The source and target classes are used by the Converter.canConvert
>>>>>>
>>>>>>> method.
>>>>>>> The Converter.canConvert method is used by the Converter factory to
>>>>>>> find
>>>>>>> the correct converter. The reason parameterized types are not used in
>>>>>>> this
>>>>>>> scenario is so you can create converters that handle entire class
>>>>>>> hierarchies. If you can think of a way to replace the Class
>>>>>>> references
>>>>>>> with
>>>>>>> parameters, that would be great. Submit a patch and I will look it
>>>>>>> over.
>>>>>>>
>>>>>>> You could submit a patch for your partially-completed ConverterChain
>>>>>>> class
>>>>>>> and maybe someone else will complete it.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 11/4/2011 2:19 AM, James Carman wrote:
>>>>>>>
>>>>>>> I was taking a look at the [convert] component because I have done
>>>>>>>
>>>>>>>> some work lately on some handy conversion classes. I'm struggling
>>>>>>>> to
>>>>>>>> understand why you'd need the getSourceClass() and getTargetClass()
>>>>>>>> methods if you're using generics.
>>>>>>>>
>>>>>>>>
>>>>>>>> Also, I've got a class that looks like this:
>>>>>>>>
>>>>>>>> public class ConverterChain<S,T> implements Converter<S,T>
>>>>>>>> {
>>>>>>>> public static<S> ConverterChain<S,S> from(Class<S>
>>>>>>>> sourceType);
>>>>>>>> public<N> ConverterChain<S,N> append(Converter<T,N>
>>>>>>>> converter);
>>>>>>>> ...
>>>>>>>> }
>>>>>>>>
>>>>>>>> I'd like to contribute it, but in my library, I don't have all of
>>>>>>>> those references to the class objects (source/target). I might
>>>>>>>> check
>>>>>>>> it in without the source/target stuff implemented.
>>>>>>>>
>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>> --**---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>>> http://apache.org**>
>>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>>>
>>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>>
>>>>>>> --**---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>> http://apache.org**>
>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>>
>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------****----------------------------**
>>>>>
>>>>> --**---------
>>>>> To unsubscribe, e-mail:
>>>>> dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>>>
>>>>> <de...@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by Adrian Crum <ad...@sandglass-software.com>.
Agreed. Please don't mis-interpret my replies - I'm not trying to "own"
the sandbox, I just want everyone to have a chance to play in it.
The recent interest in Convert is great - I hope its popularity and
usefulness grows. I'm truly looking forward to more people getting involved.
The current code base started out as a work I authored for the Apache
Open For Business Project (OFBiz). The converter framework was used for
OFBiz's scripting language. My initial work was built out and improved
upon by an excellent team of developers. When the converter framework
was fairly complete, someone suggested that OFBiz "spin off" the
converter framework to a separate library - so I brought it here to Commons.
The code you see today is currently being used in an enterprise-class
open source ERP application. It is scalable and thread-safe.
Commons Convert has not been "fed back" to the OFBiz project yet because
it is still in the sandbox. Until a decent sized community grows around
it, the OFBiz community will not be willing to switch over to it. I hope
to see that switch happen someday.
-Adrian
On 11/4/2011 11:33 AM, James Carman wrote:
> A branch would work just fine for that situation. Also, let's keep in mind
> that this component is in the sandbox
> On Nov 4, 2011 7:28 AM, "Adrian Crum"<ad...@sandglass-software.com>
> wrote:
>
>> Not so that someone else can commit them, so that others can review them
>> and comment on them.
>>
>> -Adrian
>>
>> On 11/4/2011 11:25 AM, James Carman wrote:
>>
>>> If need be, I would just create a branch for my work. It would be silly
>>> for me to submit patches so that someone else would commit them
>>> On Nov 4, 2011 7:20 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>> software.com<ad...@sandglass-software.com>>
>>> wrote:
>>>
>>> From my perspective, it would be preferable to keep the community
>>>> involved
>>>> in the design decisions.
>>>>
>>>> -Adrian
>>>>
>>>> On 11/4/2011 11:15 AM, James Carman wrote:
>>>>
>>>> I don't have to submit a patch. I am a commons committer
>>>>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>>> software.com<ad...@sandglass-software.com>
>>>>> wrote:
>>>>>
>>>>> The source and target classes are used by the Converter.canConvert
>>>>>
>>>>>> method.
>>>>>> The Converter.canConvert method is used by the Converter factory to
>>>>>> find
>>>>>> the correct converter. The reason parameterized types are not used in
>>>>>> this
>>>>>> scenario is so you can create converters that handle entire class
>>>>>> hierarchies. If you can think of a way to replace the Class references
>>>>>> with
>>>>>> parameters, that would be great. Submit a patch and I will look it
>>>>>> over.
>>>>>>
>>>>>> You could submit a patch for your partially-completed ConverterChain
>>>>>> class
>>>>>> and maybe someone else will complete it.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 11/4/2011 2:19 AM, James Carman wrote:
>>>>>>
>>>>>> I was taking a look at the [convert] component because I have done
>>>>>>
>>>>>>> some work lately on some handy conversion classes. I'm struggling to
>>>>>>> understand why you'd need the getSourceClass() and getTargetClass()
>>>>>>> methods if you're using generics.
>>>>>>>
>>>>>>>
>>>>>>> Also, I've got a class that looks like this:
>>>>>>>
>>>>>>> public class ConverterChain<S,T> implements Converter<S,T>
>>>>>>> {
>>>>>>> public static<S> ConverterChain<S,S> from(Class<S>
>>>>>>> sourceType);
>>>>>>> public<N> ConverterChain<S,N> append(Converter<T,N>
>>>>>>> converter);
>>>>>>> ...
>>>>>>> }
>>>>>>>
>>>>>>> I'd like to contribute it, but in my library, I don't have all of
>>>>>>> those references to the class objects (source/target). I might check
>>>>>>> it in without the source/target stuff implemented.
>>>>>>>
>>>>>>> ------------------------------******--------------------------**--**
>>>>>>> --**---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>>> http://apache.org**>
>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>> http://apache.org**>
>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org><
>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>> <de...@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by James Carman <ja...@carmanconsulting.com>.
A branch would work just fine for that situation. Also, let's keep in mind
that this component is in the sandbox
On Nov 4, 2011 7:28 AM, "Adrian Crum" <ad...@sandglass-software.com>
wrote:
> Not so that someone else can commit them, so that others can review them
> and comment on them.
>
> -Adrian
>
> On 11/4/2011 11:25 AM, James Carman wrote:
>
>> If need be, I would just create a branch for my work. It would be silly
>> for me to submit patches so that someone else would commit them
>> On Nov 4, 2011 7:20 AM, "Adrian Crum"<adrian.crum@sandglass-**
>> software.com <ad...@sandglass-software.com>>
>> wrote:
>>
>> From my perspective, it would be preferable to keep the community
>>> involved
>>> in the design decisions.
>>>
>>> -Adrian
>>>
>>> On 11/4/2011 11:15 AM, James Carman wrote:
>>>
>>> I don't have to submit a patch. I am a commons committer
>>>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>>> software.com<ad...@sandglass-software.com>
>>>> >>
>>>> wrote:
>>>>
>>>> The source and target classes are used by the Converter.canConvert
>>>>
>>>>> method.
>>>>> The Converter.canConvert method is used by the Converter factory to
>>>>> find
>>>>> the correct converter. The reason parameterized types are not used in
>>>>> this
>>>>> scenario is so you can create converters that handle entire class
>>>>> hierarchies. If you can think of a way to replace the Class references
>>>>> with
>>>>> parameters, that would be great. Submit a patch and I will look it
>>>>> over.
>>>>>
>>>>> You could submit a patch for your partially-completed ConverterChain
>>>>> class
>>>>> and maybe someone else will complete it.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 11/4/2011 2:19 AM, James Carman wrote:
>>>>>
>>>>> I was taking a look at the [convert] component because I have done
>>>>>
>>>>>> some work lately on some handy conversion classes. I'm struggling to
>>>>>> understand why you'd need the getSourceClass() and getTargetClass()
>>>>>> methods if you're using generics.
>>>>>>
>>>>>>
>>>>>> Also, I've got a class that looks like this:
>>>>>>
>>>>>> public class ConverterChain<S,T> implements Converter<S,T>
>>>>>> {
>>>>>> public static<S> ConverterChain<S,S> from(Class<S>
>>>>>> sourceType);
>>>>>> public<N> ConverterChain<S,N> append(Converter<T,N>
>>>>>> converter);
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> I'd like to contribute it, but in my library, I don't have all of
>>>>>> those references to the class objects (source/target). I might check
>>>>>> it in without the source/target stuff implemented.
>>>>>>
>>>>>> ------------------------------******--------------------------**--**
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>>> http://apache.org**>
>>>>>> <dev-unsubscribe@**commons.**apache.org <http://commons.apache.org><
>>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>>> >
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>> ------------------------------******--------------------------**--**
>>>>>>
>>>>> --**---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org<
>>>>> http://apache.org**>
>>>>> <dev-unsubscribe@**commons.**apache.org <http://commons.apache.org><
>>>>> dev-unsubscribe@**commons.apache.org<de...@commons.apache.org>
>>>>> >
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>> <de...@commons.apache.org>
>>> >
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [convert] API Discussion...
Posted by Adrian Crum <ad...@sandglass-software.com>.
Not so that someone else can commit them, so that others can review them
and comment on them.
-Adrian
On 11/4/2011 11:25 AM, James Carman wrote:
> If need be, I would just create a branch for my work. It would be silly
> for me to submit patches so that someone else would commit them
> On Nov 4, 2011 7:20 AM, "Adrian Crum"<ad...@sandglass-software.com>
> wrote:
>
>> From my perspective, it would be preferable to keep the community involved
>> in the design decisions.
>>
>> -Adrian
>>
>> On 11/4/2011 11:15 AM, James Carman wrote:
>>
>>> I don't have to submit a patch. I am a commons committer
>>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
>>> software.com<ad...@sandglass-software.com>>
>>> wrote:
>>>
>>> The source and target classes are used by the Converter.canConvert
>>>> method.
>>>> The Converter.canConvert method is used by the Converter factory to find
>>>> the correct converter. The reason parameterized types are not used in
>>>> this
>>>> scenario is so you can create converters that handle entire class
>>>> hierarchies. If you can think of a way to replace the Class references
>>>> with
>>>> parameters, that would be great. Submit a patch and I will look it over.
>>>>
>>>> You could submit a patch for your partially-completed ConverterChain
>>>> class
>>>> and maybe someone else will complete it.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 11/4/2011 2:19 AM, James Carman wrote:
>>>>
>>>> I was taking a look at the [convert] component because I have done
>>>>> some work lately on some handy conversion classes. I'm struggling to
>>>>> understand why you'd need the getSourceClass() and getTargetClass()
>>>>> methods if you're using generics.
>>>>>
>>>>>
>>>>> Also, I've got a class that looks like this:
>>>>>
>>>>> public class ConverterChain<S,T> implements Converter<S,T>
>>>>> {
>>>>> public static<S> ConverterChain<S,S> from(Class<S> sourceType);
>>>>> public<N> ConverterChain<S,N> append(Converter<T,N> converter);
>>>>> ...
>>>>> }
>>>>>
>>>>> I'd like to contribute it, but in my library, I don't have all of
>>>>> those references to the class objects (source/target). I might check
>>>>> it in without the source/target stuff implemented.
>>>>>
>>>>> ------------------------------****----------------------------**
>>>>> --**---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>>> <de...@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>> <de...@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by James Carman <ja...@carmanconsulting.com>.
If need be, I would just create a branch for my work. It would be silly
for me to submit patches so that someone else would commit them
On Nov 4, 2011 7:20 AM, "Adrian Crum" <ad...@sandglass-software.com>
wrote:
> From my perspective, it would be preferable to keep the community involved
> in the design decisions.
>
> -Adrian
>
> On 11/4/2011 11:15 AM, James Carman wrote:
>
>> I don't have to submit a patch. I am a commons committer
>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-**
>> software.com <ad...@sandglass-software.com>>
>> wrote:
>>
>> The source and target classes are used by the Converter.canConvert
>>> method.
>>> The Converter.canConvert method is used by the Converter factory to find
>>> the correct converter. The reason parameterized types are not used in
>>> this
>>> scenario is so you can create converters that handle entire class
>>> hierarchies. If you can think of a way to replace the Class references
>>> with
>>> parameters, that would be great. Submit a patch and I will look it over.
>>>
>>> You could submit a patch for your partially-completed ConverterChain
>>> class
>>> and maybe someone else will complete it.
>>>
>>> -Adrian
>>>
>>>
>>> On 11/4/2011 2:19 AM, James Carman wrote:
>>>
>>> I was taking a look at the [convert] component because I have done
>>>> some work lately on some handy conversion classes. I'm struggling to
>>>> understand why you'd need the getSourceClass() and getTargetClass()
>>>> methods if you're using generics.
>>>>
>>>>
>>>> Also, I've got a class that looks like this:
>>>>
>>>> public class ConverterChain<S,T> implements Converter<S,T>
>>>> {
>>>> public static<S> ConverterChain<S,S> from(Class<S> sourceType);
>>>> public<N> ConverterChain<S,N> append(Converter<T,N> converter);
>>>> ...
>>>> }
>>>>
>>>> I'd like to contribute it, but in my library, I don't have all of
>>>> those references to the class objects (source/target). I might check
>>>> it in without the source/target stuff implemented.
>>>>
>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>>> <de...@commons.apache.org>
>>>> >
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>> <de...@commons.apache.org>
>>> >
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [convert] API Discussion...
Posted by Adrian Crum <ad...@sandglass-software.com>.
From my perspective, it would be preferable to keep the community
involved in the design decisions.
-Adrian
On 11/4/2011 11:15 AM, James Carman wrote:
> I don't have to submit a patch. I am a commons committer
> On Nov 4, 2011 5:55 AM, "Adrian Crum"<ad...@sandglass-software.com>
> wrote:
>
>> The source and target classes are used by the Converter.canConvert method.
>> The Converter.canConvert method is used by the Converter factory to find
>> the correct converter. The reason parameterized types are not used in this
>> scenario is so you can create converters that handle entire class
>> hierarchies. If you can think of a way to replace the Class references with
>> parameters, that would be great. Submit a patch and I will look it over.
>>
>> You could submit a patch for your partially-completed ConverterChain class
>> and maybe someone else will complete it.
>>
>> -Adrian
>>
>>
>> On 11/4/2011 2:19 AM, James Carman wrote:
>>
>>> I was taking a look at the [convert] component because I have done
>>> some work lately on some handy conversion classes. I'm struggling to
>>> understand why you'd need the getSourceClass() and getTargetClass()
>>> methods if you're using generics.
>>>
>>>
>>> Also, I've got a class that looks like this:
>>>
>>> public class ConverterChain<S,T> implements Converter<S,T>
>>> {
>>> public static<S> ConverterChain<S,S> from(Class<S> sourceType);
>>> public<N> ConverterChain<S,N> append(Converter<T,N> converter);
>>> ...
>>> }
>>>
>>> I'd like to contribute it, but in my library, I don't have all of
>>> those references to the class objects (source/target). I might check
>>> it in without the source/target stuff implemented.
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by James Carman <ja...@carmanconsulting.com>.
I don't have to submit a patch. I am a commons committer
On Nov 4, 2011 5:55 AM, "Adrian Crum" <ad...@sandglass-software.com>
wrote:
> The source and target classes are used by the Converter.canConvert method.
> The Converter.canConvert method is used by the Converter factory to find
> the correct converter. The reason parameterized types are not used in this
> scenario is so you can create converters that handle entire class
> hierarchies. If you can think of a way to replace the Class references with
> parameters, that would be great. Submit a patch and I will look it over.
>
> You could submit a patch for your partially-completed ConverterChain class
> and maybe someone else will complete it.
>
> -Adrian
>
>
> On 11/4/2011 2:19 AM, James Carman wrote:
>
>> I was taking a look at the [convert] component because I have done
>> some work lately on some handy conversion classes. I'm struggling to
>> understand why you'd need the getSourceClass() and getTargetClass()
>> methods if you're using generics.
>>
>>
>> Also, I've got a class that looks like this:
>>
>> public class ConverterChain<S,T> implements Converter<S,T>
>> {
>> public static<S> ConverterChain<S,S> from(Class<S> sourceType);
>> public<N> ConverterChain<S,N> append(Converter<T,N> converter);
>> ...
>> }
>>
>> I'd like to contribute it, but in my library, I don't have all of
>> those references to the class objects (source/target). I might check
>> it in without the source/target stuff implemented.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [convert] API Discussion...
Posted by Adrian Crum <ad...@sandglass-software.com>.
The source and target classes are used by the Converter.canConvert
method. The Converter.canConvert method is used by the Converter factory
to find the correct converter. The reason parameterized types are not
used in this scenario is so you can create converters that handle entire
class hierarchies. If you can think of a way to replace the Class
references with parameters, that would be great. Submit a patch and I
will look it over.
You could submit a patch for your partially-completed ConverterChain
class and maybe someone else will complete it.
-Adrian
On 11/4/2011 2:19 AM, James Carman wrote:
> I was taking a look at the [convert] component because I have done
> some work lately on some handy conversion classes. I'm struggling to
> understand why you'd need the getSourceClass() and getTargetClass()
> methods if you're using generics.
>
>
> Also, I've got a class that looks like this:
>
> public class ConverterChain<S,T> implements Converter<S,T>
> {
> public static<S> ConverterChain<S,S> from(Class<S> sourceType);
> public<N> ConverterChain<S,N> append(Converter<T,N> converter);
> ...
> }
>
> I'd like to contribute it, but in my library, I don't have all of
> those references to the class objects (source/target). I might check
> it in without the source/target stuff implemented.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [convert] API Discussion...
Posted by Simone Tripodi <si...@apache.org>.
Hi James,
I had a look at current [convert] impl and the (source|target)Class
are used to index converters inside a generic universal converter, so
all you have to do is invoking just one method to perform conversions
- without retrieving the converter you need on your client
application.
Your hints are more or less what I had in my mind too, after you
suggested having fluent APIs in the Digester I'm kind of addicted to
them :P
I'd suggest to replace the (source|target)Class settings by hand
applying the `TypeLiteral` pattern explained in Neal Gafter's post[1]
to auto-discover them.
Have a nice day, all the best!
Simo
[1] http://gafter.blogspot.com/2006/12/super-type-tokens.html
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Nov 4, 2011 at 3:19 AM, James Carman <ja...@carmanconsulting.com> wrote:
> I was taking a look at the [convert] component because I have done
> some work lately on some handy conversion classes. I'm struggling to
> understand why you'd need the getSourceClass() and getTargetClass()
> methods if you're using generics.
>
>
> Also, I've got a class that looks like this:
>
> public class ConverterChain<S,T> implements Converter<S,T>
> {
> public static <S> ConverterChain<S,S> from(Class<S> sourceType);
> public <N> ConverterChain<S,N> append(Converter<T,N> converter);
> ...
> }
>
> I'd like to contribute it, but in my library, I don't have all of
> those references to the class objects (source/target). I might check
> it in without the source/target stuff implemented.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org