On 16 Jul 2009, at 11:24, David Chisnall wrote:
On 16 Jul 2009, at 09:30, Richard Frith-Macdonald wrote:
But ... going back to the issue of avoiding changes to ivars
breaking ABI in future releases ... the approach I currently favor
is having a *single* ivar in the public class. This is a private
id variable referring to an instance of a private class which is
used to hold the real ivars.
I really don't like this approach. It makes the code difficult to
read, destroys locality of reference, and hurts performance.
Please, please, please, can other people test my non-fragile ivars
patch so that we can get rid of ugly hacks like this and just not
declare any ivars in the headers. I posted it months ago and have
had absolutely no reports of testing yet.
Sorry, I just haven't had a chance to look at installing a new/
different compiler and working with that yet, though it really IS
something I'd like to be playing with.
However, it doesn't really have any bearing on this issue because we
have to develop code for the existing compiler and will need to do so
as long as we continue to support it (gcc).
I honestly can't see gcc being dropped any time soon (in the first
place we would want all GNUstep to have been working flawlessly with
clang for a good long time... perhaps a year) before we could
reasonably think of making Clang the preferred compiler, let alone
deprecating or removing support for gcc, and in the second place there
may be political considerations preventing it (though I think most of
the core developers are less likely to be bothered about that than in
many free software projects ).
I think we have to live within the limitations of gcc as long as we
haven't deprecated it.
The nice thing about this particular scheme (a single instance
variable in the public class pointing to another class containing the
actual variables) is that it's clean and simple enough to make it
*very* easy to change if/when we change compilers at a later date.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
