commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [convert] API Discussion...
Date Sat, 05 Nov 2011 15:21:02 GMT
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 <james@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
> <adrian.crum@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"<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
>>
>>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message