Am 14.08.2013 16:54, schrieb Gary Gregory: > 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.
Well, no objections. I only took [csv] as an example. The proposal was related to [convert]. Oliver > > > 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
