Re: @property problem

FROM : Bill Bumgarner
DATE : Sun Feb 17 19:03:07 2008

On Feb 17, 2008, at 9:47 AM, William Squires wrote:
> On Feb 17, 2008, at 11:13 AM, Jim Correia wrote:

>> On Feb 17, 2008, at 11:59 AM, William Squires wrote:

>>> But it doesn't answer the question. Why even make the change in 
>>> the 64-bit runtime? This would seem to hide a source of bugs, by 
>>> taking the responsibility for providing storage away from the 
>>> programmer. Some storage is still necessary.

>> As it stands, you cannot add iVars to a base class in the 32-bit 
>> runtime without required that all subclasses be recompiled.

>  ??? Why should the subclasses know anything about the base class 
> other than what the base class exposes in its API (from the POV of 
> whomever is writing the subclass code, if they follow proper OO 
> methodologies)? Only if I rewrite the subclass to specifically use 
> the new iVar should I need to recompile it.
>  i.e. If I have a base class A


It is an implementation detail.

In the legacy -- 32 bit -- runtime, each subclass effectively tacks 
its instance variables onto the end of the superclass's instance 
variables as if it were all one big extensible C structure.  If the 
superclass adds an ivar, the offset of the ivars in said structure are 
thus incorrect and, unless you recompile, subclasses will read/write 
from the wrong spot in memory and *boom*.

The modern -- 64 bit -- runtime fixes this particular issue.

>

>> This is particularly important for frameworks like AppKit. An 
>> AppKit class cannot have an iVar added to it because it would break 
>> binary compatibility with everyone who subclassed it. The 64-bit 
>> runtime solves this problem.
>>

> How? And, more importantly, why? What advantage is added by hiding 
> the need for the storage? And what happens if you follow the older 
> model and still provide the storage anyway?


In the modern runtime, it doesn't matter if you have properties 
synthesize the storage or you declare the storage explicitly, you can 
still modify the superclass's inventory of instance variables -- 
explicitly or through synthesis -- without requiring subclasses to be 
recompiled.

There is a very good reason for "hiding the storage" -- for 
synthesizing the storage of an instance variable. By doing so, you 
force all access to said instance variable to go through either the 
synthesized setter/getter or your own implementation of the setter/
getter.  Without jumping through some significant hoops, some random 
bit of code external to your class isn't going to be able to diddle 
the instance variables of your class directly.

>>> And besides, in order to take advantage of Leopard features like 
>>> this one (whether on PPC or Intel), you should still have to link 
>>> against the 10.5 SDK, so it would seem more reasonable to make the 
>>> update to both the 32 and 64-bit runtimes, but only in the 10.5 
>>> SDK. Then you could update the 10.5 SDK (to 10.5.1) to allow for 
>>> this "syntactic sugar" under both 32- and 64-bit.
>>> I mean, after all, all it means is that you're changing the 
>>> default size of an (Integer) register in the CPU chip, and 
>>> updating the OS to take advantage. How would this make 
>>> implementing (or not implementing) this change any harder or easier?

>>
>> The 32-bit runtime must remain binary compatible with all code that 
>> was compiled and targeted for Tiger and earlier.
>>
>> It is extremely desirable to be able to link against the 10.5 SDK 
>> and still deploy your application on Tiger (after taking 
>> appropriate measures.)

>  Huh? I thought the point of linking against a new SDK was to take 
> advantage of features in that SDK, not to maintain backwards 
> compatibility with the older OS features?


Linking against a new SDK provides for the ability to take advantage 
of the new API provided by said SDK.

But this isn't an API issue, this is an ABI issue.  The features of 
the modern runtime *** REQUIRE *** a different ABI that is 
incompatible with prior releases of Mac OS X.

Thus, the decision was made to only offer the modern runtime features 
for 64 bit applications on Leopard and beyond.  There was no binary 
compatibility issues as there was no prior release of Mac OS X that 
offered 64 bit Objective-C support.

b.bum