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@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev
