[cffi-devel] Converting foreign structures with CFFI generic functions

Luís Oliveira luismbo at gmail.com
Mon Sep 5 14:16:50 UTC 2011


On Mon, Sep 5, 2011 at 4:43 AM, Liam Healy <lnp at healy.washington.dc.us> wrote:
> (defcstruct (complex :constructor complex :deconstructor (realpart imagpart))
>   (dat :double :count 2))
>
> You can get a pretty good sense of what the :constructor and
> :deconstructor args do quickly, and I bet most people could write
> their own defcstruct and appropriate converter quickly with no trips
> to the manual.
[...]
> No one would be forced to use the macro, you could still write the
> defmethods by hand as you propose.  Macros eliminate or minimize cut
> and paste.

My broader point, I guess, is that one must be careful not to mistake
concision for abstraction and that the latter is more important.
Anyway, I understand your point. Let's get the plumbing right first,
and we'll get back to the macro sugar later.


> I don't envision making CLOS objects the CL equivalent of foreign
> structures I need (I assume you mean of CLOS object of metaclass
> standard-class), but I have no objection to providing some default
> methods.   My inclination would be to make the default CL equivalent a
> list.   That's how it is for fsbv:defcstruct.   It is unclear to me
> how making CLOS objects simplifies the recursive conversion task.

I don't think using CLOS objects has any impact on handling
recursiveness. I started thinking about conversion to CLOS and mixed
things up, sorry.


> I don't understand your BTW statement.

I was just mentioning that a possible default translation could be to
make an opaque object with accessors that handle translations on
demand. Not a very important issue at this point. We can discuss it
later.


> If CFFI had a translate-into-foreign-memory, then a
> translate-to-foreign could be an ordinary function:
> (translate-into-foreign-memory source type (foreign-alloc type))
> Wouldn't that do everything it needs to?

Pretty much, yeah.


> (BTW, I get confused by foreign-alloc's :initial-element/contents
> arguments.  Is this calling translate-to-foreign?  It seems like it
> presumes some kind of translation facility.  Or does it simply do
> nothing if type is a foreign structure?)

initial-element and contents will in fact go through
translate-to-foreign, IIRC. Is that an issue?


> I don't know what expand-into-foreign-memory is.

Have a look at:
<http://common-lisp.net/project/cffi/manual/html_node/Optimizing-Type-Translators.html>.

Cheers,

-- 
Luís Oliveira
http://r42.eu/~luis/




More information about the cffi-devel mailing list