On Thu, Sep 8, 2011 at 11:36 AM, Attila Lendvai <attila.lend...@gmail.com> wrote: > On Thu, Sep 8, 2011 at 13:15, Luís Oliveira <luis...@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 _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
