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

Liam Healy lnp at healy.washington.dc.us
Thu Sep 8 16:39:20 UTC 2011


On Thu, Sep 8, 2011 at 11:36 AM, Attila Lendvai
<attila.lendvai at gmail.com> wrote:
> On Thu, Sep 8, 2011 at 13:15, Luís Oliveira <luismbo at gmail.com> wrote:

> 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?

>> Suggestions on how to best handle backwards-incompatible API changes
>> like this are most welcome.
>
>
> my 0.02: tag the repo, make a big fat warning in the commit message,
> and go on developing.
>
> --
>  attila

I agree on the strategy where an incompatible change is necessary, but
in this case in particular I don't see that a backwards-incompatible
change is necessary.   Can't we by default make defcstruct objects
instances of enhanced-foreign-type by default without negatively
affecting call-by-reference applications?  If not, we can add an
optional argument, but I'm concerned about cases where we need both
call by ref and by value.

Liam




More information about the cffi-devel mailing list