From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110008 invoked by alias); 30 Mar 2015 16:32:17 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 109927 invoked by uid 89); 30 Mar 2015 16:32:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: mail.theptrgroup.com Received: from Unknown (HELO mail.theptrgroup.com) (71.178.251.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Mar 2015 16:32:15 +0000 Received: from [10.11.21.70] (unknown [10.11.21.70]) by mail.theptrgroup.com (Postfix) with ESMTPS id EC4312A023 for ; Mon, 30 Mar 2015 12:32:02 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Kawa type-conversions From: Jamison Hope In-Reply-To: <551610A8.4070504@bothner.com> Date: Mon, 30 Mar 2015 16:32:00 -0000 Content-Transfer-Encoding: 7bit Message-Id: <4831FF97-7D5B-4F09-9EE4-83F9C8E7668D@theptrgroup.com> References: <550C7D9C.7030102@bothner.com> <3E31B880-0FD8-4C1B-8EA5-15ED388861D7@theptrgroup.com> <551610A8.4070504@bothner.com> To: "kawa@sourceware.org list" X-IsSubscribed: yes X-SW-Source: 2015-q1/txt/msg00071.txt.bz2 On Mar 27, 2015, at 10:23 PM, Per Bothner wrote: > You discuss an extra search mechanism > (convention) for explicit conversion, but I don't understand how > that so much more convenient than just re-defining the ->TYPE function. If all of the source is being compiled together, then perhaps it isn't, except that it avoids having to explicitly group all of the possible conversions together into a big case-lambda or whatever. The search mechanism would make ->TYPE more akin to a CLOS generic function, where the backing methods could be in separate modules. Anyway, my thought was for separately-compiled libraries. For example, suppose I've got a textbook shape class library with a bunch of useful functions to do things like calculate the minimum distances between pairs of shapes (sphere/sphere, prism/cylinder, etc). Everything is working fine, and then the boss says that I need to support JBullet shape primitives. Knowing how these things go (next week it'll be ode4j or some other package instead of JBullet), instead of making a bunch of huge changes to the guts of my library, I change my top-level functions: (define (calculate-distance s1::com.example.shape s2::com.example.shape) ::real ...) becomes (define (calculate-distance o1 o2) ::real (let ((s1 (->com.example.shape o1)) (s2 (->com.example.shape o2))) ...)) I then compile that to a JAR and never touch it again. To support JBullet, I then write a helper library which does the conversion between JBullet shapes and com.example.shape, and then make sure that JAR gets loaded any time I have to support JBullet shapes. Likewise for ode4j and the next third-party library that comes along. If I just redefine ->TYPE, then I end up needing 2^n different re-definitions, for all of the possible combinations of "from" types. In this example, I would need one that just handles JBullet shapes, another which just handles ode4j shapes, a third which handles both, etc. (Again, the problem is the big generic procedure with everything all in one place. That means to compile/load that one function, I would need to load the classes of all types mentioned by that function.) Does all that make sense? Maybe this isn't the job of ->TYPE, maybe it's some other COERCE-like function which does runtime (not compile-time) lookup to enable the kind of modularity I've described? -- Jamison Hope The PTR Group www.theptrgroup.com