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:34:55 GMT
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 <james@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
> <simonetripodi@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 <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
>>
>>
>
> ---------------------------------------------------------------------
> 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