Re: Next release

[Helge Hess]

On 08.03.2008, at 00:33, Gregory John Casamento wrote:
> Currently there is a lot of space which is marked as "reserved" in  
> Apple's header files.   This allows for future additions without  
> changing the memory layout of the class which is what leads to ABI  
> issues and subsequently the need for recompilation.

Didn't that change in Objective-C 2.0 / the 64bit ABI? I thought the  
fragile base class problem is no more? (due to ivar indirection).

> The trick is to reserve just the right amount of space so that you  
> don't make your classes needlessly big

Well, the instances would be big, not the classes :-)

> Another potential solution to this problem, a bit different from the  
> one above and probably a little risky is to simply have a void  
> pointer in each class' ivar section and have it point to the  
> appropriate structure when initialized during runtime.

I *guess* thats how its implemented in ObjC 2.0. The class probably  
doesn't contain the ivars directly, but just a pointer to the ivar  
block of the specific class.
But I didn't check. Maybe someone else knows more.

> The third option is to get gui to a point where it's ABI is actually  
> stable.  Consider that base hasn't changed much for a long time.

The ABI unfortunately *did* change a lot, I outlined that in detail  
several times, please check the archives.
Stable ABI is not just ivar layout, but also stable method behaviour  
and constant public API (no public methods added!/changed, no classes  
added/changed, no methods moved to categories etc etc). Having a  
stable ABI might even imply preserving certain kinds of bugs :-)

I can't say how stable the GUI ABI is, but the base ABI definitely is  
NOT stable at all (just say KVC ;-).
And *please* remember that I don't refer to the stability of the code,  
but to the stability of the ABI only. The stability of the code is  
very nice, so if you don't have a problem with staying at trunk / last  
branch, everything is awesome-O :-) We do.

Thanks,
  Helge
--
Helge Hess
http://www.helgehess.eu/