Re: @property problem

FROM : William Squires
DATE : Sun Feb 17 19:52:16 2008

On Feb 17, 2008, at 12:03 PM, Bill Bumgarner wrote:

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

Okay, that explains it - weird... I wonder why ObjC did that?

>>

>>> 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