On 5 Mar 2009, at 20:27, David Chisnall wrote:
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é).
That's interesting. What sort of introspection do you do which needs
to know about the layout of private ivars? Shouldn't the KVC/KVO
facilities be enough?
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.
You are referring to the NSZone thing? Of course that hasn't been
done. We need people checking/using svn trunck to make sure we deal
with any temporary breakage (or any completely accidental breakage)
before a release.
I feel we probably need to break things in trunk during the
development cycle to get a reaction and some suggestions from other
people. For instance I asked for ideas about the change to using
NSUInteger,NSInteger, and CGFloat, and I adopted your idea of a
#define to retain the old style behacvior, but since then I've seen no
feedback about making this change work with gui/back and other apps.
What I probably need to do is switch that code to use the new Apple
behavior by default, deliberately breaking 64bit systems so that
people will do something about it, or will at least sned specific bug
reports for me to deal with.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev