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