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

[Luís Oliveira]

On Tue, Sep 6, 2011 at 4:23 AM, Liam Healy <lnp at healy.washington.dc.us> wrote:
> On the contrary, it's welcome.  Can we add these to
> with-foreign-object(s) too?  Notice (http://repo.or.cz/w/fsbv.git)
> fsbv:with-foreign-objects has
> bindings ::= {(var type &optional initial-value)}*
> This is another macro sugar issue, so no problem deferring, but it's
> be nice to have ultimately.

Oh yes, with-foreign-object should definitely accept the same
arguments as foreign-alloc.


>> Have a look at:
>> <http://common-lisp.net/project/cffi/manual/html_node/Optimizing-Type-Translators.html>.
>
> OK, so it's an optimization issue.  Can this be deferred until later?

Definitely.


On Thu, Sep 8, 2011 at 5:23 AM, Liam Healy <lnp at healy.washington.dc.us> wrote:
> 6. Finding that (parse-type 'complex) is an instance of neither
> ENHANCED-TYPEDEF nor ENHANCED-FOREIGN-TYPE, the expand-from-foreignT T
> method is called, which just returns value (first arg).
>
> So there's a gap here, and I'm not sure how to plug it.  Should I be
> making complex-type a subclass of enhanced-foreign-type so that the
> compiler macro picks up the conversion to lisp?

Oh. That's right, unless it's an enhanced-foreign-type it won't go
through the translation mechanism. Adding that as superclass should
work.

I think we need a new DEFCSTRUCT-like macro, let's call it DEFCSTRUCT*
for now. *sigh*

With a different macro we can (a) implement call-by-value semantics by
default, (2) add the enhanced-foreign-type superclass by default, and
probably (3) have a sane value for :CLASS, not sure.

Does that makes sense?

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