On 19 Jun 2009, at 17:30, Stefan Bidigaray wrote:
Then the designated initialiser allocates memory for the structure,
clears it, and assigns the pointer when an instance is initialised,
and -dealloc frees the memory at the end, and all internal
references to ivars just go indirect from that pointer. The
implementation is completely hidden/private and can be changed in
subsequent releases without breaking the ABI.
Should I do this instead? Fact of the matter is, I'm not sure if
the way I'm going about this is the best way forward, so chances are
it'll eventually change (hence why I created an array of 4 (void *)
but am only using 3 pointers). I would gladly go this route,
specially since, like everyone else here, I'm all for ABI
compatibility.
While we're talking about this, has anyone apart from me tested the
non-fragile ivars support that is now in clang and works with the
libobjc patch I posted here a month or so ago? When we have non-
fragile ivars, this problem goes away; just do what Apple does and
don't declare any ivars in the public headers, then have a version of
the @interface in the .m file that does. This works nicely for me,
but it needs further testing before I push the libobjc diff upstream.
David
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
