Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A826310E8A for ; Wed, 14 Aug 2013 19:29:37 +0000 (UTC) Received: (qmail 35755 invoked by uid 500); 14 Aug 2013 19:29:36 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 35672 invoked by uid 500); 14 Aug 2013 19:29:36 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 35650 invoked by uid 99); 14 Aug 2013 19:29:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Aug 2013 19:29:35 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [212.227.17.10] (HELO moutng.kundenserver.de) (212.227.17.10) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Aug 2013 19:29:29 +0000 Received: from [192.168.178.21] (dslb-088-069-235-083.pools.arcor-ip.net [88.69.235.83]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0M5V8e-1W2S8i10ae-00xbYS; Wed, 14 Aug 2013 21:29:08 +0200 Message-ID: <520BDA82.5010804@oliver-heger.de> Date: Wed, 14 Aug 2013 21:29:06 +0200 From: Oliver Heger User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Commons Developers List Subject: Re: [convert] Automatic conversion based on proxies References: <520A90A3.6020603@oliver-heger.de> <520BA4B3.8070308@sandglass-software.com> In-Reply-To: <520BA4B3.8070308@sandglass-software.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:1uf9mDfliwIU3ro8VwFGJLtIjEnC3ivyG4ZMxJLaG4V zcCm2S0WzQrWSldPyAxmc8rtXAZ8Up95GgIwcHMfmhmIv2zVcZ 8vkIcHisnuyIYPiRQvblTLXK2HIaJ9Y9D6jDl4+usYXWmEeoNe RcWJShtwu2A+ht1j0Y6zLAG5fRwXBjReBPjwGkDb3e9ikjEhaH uC/drZO+Rm99J6AcKjt5iZNzQzMHmOSzOjbf6kTxB+CLzrPs1y U6txRwOmClKT7CTQ9pyZUIx679osXtD8dRkB0OMgCHFzVmosVC uGyIGYQaPg0k+Ke57JqP5wNCz3Oq+IilnE+qL+GT+CC9CF8drI AG3g2k07tB96kQdsXzf4= X-Virus-Checked: Checked by ClamAV on apache.org 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: > > > > > > > > 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 >> 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