• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: @property problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: @property problem


  • Subject: Re: @property problem
  • From: Jean-Daniel Dupas <email@hidden>
  • Date: Sun, 17 Feb 2008 20:18:47 +0100


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.


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >@property problem (From: Randall Meadows <email@hidden>)
 >Re: @property problem (From: Joshua Emmons <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)
 >Re: @property problem (From: Jean-Daniel Dupas <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)
 >Re: @property problem (From: Jim Correia <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)
 >Re: @property problem (From: Bill Bumgarner <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)

  • Prev by Date: Re: [Foo new] vs [[Foo alloc] init]:
  • Next by Date: Re: Exited abnormally: Broken pipe
  • Previous by thread: Re: @property problem
  • Next by thread: Re: @property problem
  • Index(es):
    • Date
    • Thread