On Sat, Aug 27, 2011 at 5:05 PM, Liam Healy <l...@healy.washington.dc.us> wrote: > My thought now is that I should define methods for translate-*-foreign and > free-translated-object dispatching on the foreign-struct-type class.
That makes sense. The type object should have all the necessary info you need to construct whatever objects libffi requires. (I'm not familiar with the libffi API.) I.e., you shouldn't need to define specific translation methods for each struct type definition. > The body will call the same method with the structure name, and applications >can > define methods eql-specialized on the name. I don't think that's necessary. DEFCSTRUCT takes an undocumented class argument that allows for specialization based on class rather than using EQL-specializers. I'm guessing you're thinking about stuff like converting CLOS objects into C structs. That is something that hasn't been properly explored in CFFI. See the undocumented DEFINE-C-STRUCT-WRAPPER for a half-baked go at that problem. > Does this sound like it will > work correctly with CFFI as it exists now, so that I can then introduce the > libffi interface for the calls to foreign functions? What kind of translation do you need these methods to do on FOREIGN-STRUCT-TYPE? Cheers, -- Luís Oliveira http://r42.eu/~luis/ _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
