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é).