On 09/09/2012 21:05, Marvin Humphrey wrote:
void
Sub_method(void *self) {
Sub_MEMBERS *members = Sub_get_members(self);
members->sub_num = 1;
members->sub_float = 1.0;
// Only safe if Base is in the same parcel
Base_MEMBERS *base_members = Base_get_members(self);
base_members->base_num = 1;
base_members->base_float = 1.0;
}
I'd originally thought to avoid this approach because of the extra line of
code, but perhaps it's not so bad after all. Plus, there's an idiom for
single line access;
void
Foo_set_num(Foo *self, int num) {
Foo_MEMBERS(self)->num = num;
}
Yes, I think we can live with that extra line.
Bikeshedding questions: MEMBERS, or IVARS? Or both? Or something else?
`IVARS` -- an abbreviation of "instance variables" saves two letters. (Also
FWIW, in Java and C++ both "class variables" and "instance variables" are
"member variables" -- so "members" is a superset.)
I like 'IVARS'. It seems to come from Objective-C and AFAICS our
solution is similiar to the one of the modern Objective-C runtime.
void
Sub_method(void *self) {
Sub_IVARS *ivars = Sub_MEMBERS(self);
ivars->sub_num = 1;
ivars->sub_float = 1.0;
// Only safe if Base is in the same parcel
Base_IVARS *base_ivars = Base_MEMBERS(self);
base_ivars->base_num = 1;
base_ivars->base_float = 1.0;
}
`Sub_get_members` bothers me because it doesn't use the all caps convention
which we've informally reserved and therefore looks like userland code.
(`Foo_num` bothers me for the same reason.) Also the underscore in the type
name "Sub_MEMBERS" bothers me, but I guess SubMEMBERS isn't a good
alternative.
I don't like mixing 'IVARS' and 'MEMBERS', but I don't have a strong
opinion on symbol names.
The biggest drawback I can see is that objects become void pointers, and
we'll lose some of the type-checking that the C compiler currently performs
for us. But that's something other solutions to the fragile base class
problem will also have to deal with.
Is using void pointers really mandatory? I'm not seeing it.
I think we can continue to use struct types for classes. We still get the
type checking benefits even if we never define the struct layout and leave the
type opaque.
Yes, of course. I wasn't thinking clearly.
Nick
