Greets,
The IVARS fix that Nick proposed for the fragile ABI problem posed by member
variables has been implemented, on branch ivars-wip1.
If you define an instantiable `class Foo` with the parcel "Stuff", Clownfish
will generate a `stuff_FooIVARS` struct definition and a `stuff_Foo_IVARS`
inline function to get at it.
Foo*
Foo_init(Foo *self, int count, float score) {
FooIVARS *const ivars = Foo_IVARS(self);
ivars->count = count;
ivars->score = score;
return self;
}
int
Foo_get_count(Foo *self) {
return Foo_IVARS(self)->count;
}
Implementation detail: the inline function adds the value of a per-class,
parcel-scoped `size_t` variable named e.g. `stuff_Foo_IVARS_OFFSET` to the top
of the object.
Member variables are now parcel scoped. With regards to visibility of member
vars within a parcel, I made a judgment call that the IVARS structs for
subclasses would include variables declared in superclasses if those
superclasses are in the same parcel. For example: the TermQueryIVARS struct
definition includes the `boost` member that is declared in Query.
Classes within the Clownfish runtime still have members defined within their
object structs and do not use IVARS. I'm of two minds as to whether we should
go and update them to use IVARS for the sake of consistency, pound-defining
the IVARS_OFFSET symbols as integer constants by default but allowing for the
possibility of an override. I'm not sure there's any use case where we'd need
a variable-sized object head.
Marvin Humphrey
