commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adrian.c...@sandglass-software.com>
Subject Re: [convert] API Discussion...
Date Fri, 04 Nov 2011 12:15:26 GMT
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"<adrian.crum@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<adrian.crum@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<adrian.crum@**sandglass-software.com<adrian.crum@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<dev-unsubscribe@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<dev-unsubscribe@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<dev-unsubscribe@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<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


Mime
View raw message