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