On 5 Mar 2009, at 16:10, Gregory Casamento wrote:
The last collective release was only two months ago.
As far as the ABI is concerned that is certainly an issue. The
last time we discussed it we came up with two solutions:
• Pad the ivar-structures in the classes out to give space to grow
so that it pushes off any ABI compatibility issues as long as
possible. This is why in some APIs, including Cocoa, you see
things like "reserved..." or "private..." variables. These are
there to give room to grow. The disadvantage is that the classes
would then take up more memory as a result.
• Move the ivar-structures out of the classes and replace them with
a void pointer to the actual structure. This has the advantage
that we will never be able to break ABI compatibilty since the sizes
of the structs in the classes will not change... but it also has the
disadvantage of adding a layer of complexity to getting and setting
variables as well as potentially causing unpredictable issues due to
unforseen incompatibilities such as cases where the wrong data is
written into a data structure causing some sort of corruption when
using the wrong version of a library.
Or, option 3, use non-fragile ivars. I plan on adding support for
this to the GNU runtime and the clang implementation over the next few
weeks. It can be done without breaking the existing GNU runtime ABI
an, although it won't work retroactively, will let us change the ivar
layout of classes without subclasses requiring recompilation. (Oh,
please, please, don't do option 2 - it would break a lot of the
introspection that we use heavily in Étoilé).
Of course, this only applies to classes. When people decide to remove
global variables that are referenced by static functions declared in
headers, this will still break the ABI, and really shouldn't have been
committed without a period of at least a year while the relevant
symbol was marked as deprecated.
David
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev