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>
-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
