> On 7 Nov 2016, at 14:53, Nicolas Passerini <[email protected]> wrote: > > Well, maybe we can do it for Pharo 7.
unless of course we find that doing it like this is incredibly easy and also we can do an “automigration tool” style the autodeprecation tool ;) Esteban > > 2016-11-07 14:46 GMT+01:00 Esteban Lorenzano <[email protected] > <mailto:[email protected]>>: > >> On 7 Nov 2016, at 14:39, Nicolas Passerini <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> 2016-11-07 10:37 GMT+01:00 Denis Kudriashov <[email protected] >> <mailto:[email protected]>>: >> NativeStructure >> subclass : #SDL_Point >> layout : StructureLayout >> slots: { #x &=> #int. #y &=> #int} >> ... >> (I got example of Ronie definition from his paper >> https://hal.inria.fr/hal-01353884/document >> <https://hal.inria.fr/hal-01353884/document>). >> So all offsets logic will go to one place StructureLayout and slots. And >> also we will not forced to use accessors anymore. >> >> I like this idea. >> But one question, would it be backwards compatible? (I mean, if I have >> current FFI invocations that use a structure in the traditional way, will I >> have to change all these functions if I try to migrate to this new idea?) > > no, and that’s why I didn’t considered it for now. > this is an api change, non backwards compatible and then it breaks my own > criteria about Pharo6 development: no more API changes. > > but yes, in general, I like the idea… just we cannot break things just like > that (I know, I break things… but this is not willingly :P) > > Esteban > >
