Re: @property problem
Re: @property problem
- Subject: Re: @property problem
- From: William Squires <email@hidden>
- Date: Sun, 17 Feb 2008 12:52:16 -0600
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
_______________________________________________
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