Re: @property problem

FROM : Jean-Daniel Dupas
DATE : Sun Feb 17 20:18:47 2008

Le 17 févr. 08 à 19:52, William Squires a écrit :

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


That's not an obj-c issue. That's a runtime and compiler issue. If you 
want to know why the OS X runtime did that, you will have to go back 
to the NeXT's days.