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.c...@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.c...@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.c...@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-unsubscr...@commons.apache.org>
>>>>>> >
>>>>>> For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org>
>>>>> >
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>> <dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org>
>>> >
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail:
> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
