commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [convert] Automatic conversion based on proxies
Date Wed, 14 Aug 2013 19:29:06 GMT
Am 14.08.2013 17:39, schrieb Adrian Crum:
> I don't think CSV needs anything special to accommodate type conversion.
> 
> The pattern I tried to introduce in the Commons Convert "Getting
> Started" section is one that works in any part of an application where
> conversion might be needed. So, instead of hard-coding conversions, the
> developer creates a facade that accommodates conversion anywhere in the
> program (not just in CSV).
> 
> Instead of
> 
> int columnInt = record.getValueAsInt(1);
> 
> the developer would use
> 
> Integer columnInt = Util.convertTo(record.getValue(1), Integer.class);
> 
> By keeping type conversion separated, you can convert anything you
> encounter during development. Plus, this approach relieves CSV from
> being concerned with conversions - that is the developer's responsibility.
> 
> If a developer used Commons Convert, then they could keep conversion
> details out of the code entirely and design external declarative
> conversions:
> 
> <file-reader>
>   <input-file name="dailyForex" format="CSV" />
>     <field name="fromCurrency" type="java.lang.String" />
>     <field name="toCurrency" type="java.lang.String" />
>     <field name="conversionRate" type="java.lang.Double" />
>   </input-file>
> </file-reader>

I see. It's just in times of CDI developers expect that everything
happens automagically.

Oliver

> 
> -Adrian
> 
> 
> On 8/14/2013 7:54 AM, Gary Gregory wrote:
>> On Tue, Aug 13, 2013 at 4:01 PM, Oliver Heger
>> <oliver.heger@oliver-heger.de>wrote:
>>
>>> Hi all,
>>>
>>> recently, there was a discussion about extending the [csv] interface to
>>> provide data conversions to different types. If such a use case is to be
>>> supported, what would be the best approach to integrate a library like
>>> [convert]?
>>
>> Well, the first step would be to release [Convert] 1.0 ;)
>>
>> It seems there would first need to be agreement that conversion
>> belongs in
>> [csv] in the first place, which is not the case for [CSV] 1.0.
>>
>> Personally, I'd like to focus on getting [CSV] 1.0 out the door and then
>> adding features.
>>
>> It is good to talk about conversion now of course because it may
>> affect the
>> [CSV] APIs we provide. We do want to be backward compatible.
>>
>>
>> Gary
>>
>>
>>> Doing all required conversions manually would probably mean a
>>> bunch of boilerplate code, wouldn't it?
>>>
>>> I had an idea how to automate this use case. Given an interface with a
>>> method
>>> T getValue(...);
>>> where T is some base type like String or Object. Now we want to provide
>>> other methods like
>>> int getValueAsInt(...);
>>> long getValueAsLong(...);
>>> ...
>>>
>>> If there is an extended interface with all getValueAsXXX() methods,
>>> couldn't the conversion be done by a proxy? The invocation handler would
>>> obtain the return type of the invoked method in order to determine the
>>> target class of the conversion. It would then call the basic getValue()
>>> method with the provided arguments, convert the result, and return it.
>>>
>>> This is the general idea, in practice probably some filtering would be
>>> needed to react only on certain method invocations.
>>>
>>> Do you think this use case is generic enough to support it in [convert]
>>> (e.g. by providing an abstract base class of an invocation handler and
>>> some convenience methods for creating proxy objects)?
>>>
>>> Oliver
>>>
>>> ---------------------------------------------------------------------
>>> 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