Re: @property problem
Re: @property problem
- Subject: Re: @property problem
- From: William Squires <email@hidden>
- Date: Sun, 17 Feb 2008 11:47:04 -0600
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
@interface
class MyObject : NSObject <- Yeah, I know this isn't needed, just
there 'cause I'm retentive :)
{
int iMyIVar;
}
- (id) init;
- (void) printMe;
- (int) myIVar;
- (void) setMyIVar: (int) i;
@end
and I make another class B that inherits from it, then if I only use
this API (by #import "MyObject.h") in my code, I should be okay even
if someone adds a new property or method, since my code doesn't even
look at the new stuff. That is, if I do:
...
{
MyObject *myObj = [[MyObject alloc] init];
...
}
somwehere, then *myObj points to some data structure in memory (a C
struct) that contains the iVars, and a "smart" pointer to the method
implementations I can reach via the API (i.e. the public '-' methods
in the @interface section). So all my class B cares about is that a
"MySubObject *" points to a data structure, one of whose elements
(iVars) is "iMyIVar" of type (int) (because it's inherited from
MyObject), and that I can get to not only my methods, but any
inherited methods through the "smart" pointer in that data structure.
And really, I shouldn't even access the "iMyIVar" in the subclass
except through the inherited accessors (getters/setters), so I
shouldn't even need to know what iVars are in the base class, just
the accessors for them (which are methods.) So even if Apple's
software engineers decide to add an iVar to some NS framework class
(or class cluster), I shouldn't care unless I want to look at the
documentation to see what new methods (including accessors) are
available in that class. Then I'd have to recompile my subclass in
any event because I changed the code.
Right?
Now it'd be different if the REMOVED a method - that would be bad
mojo! :(
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?
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?
By restricting this changes to the 64-bit runtime, all binary
compatibility issues are avoided, because there are no legacy 64-
bit applications.
Jim
_______________________________________________
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:
40satx.rr.com
This email sent to email@hidden
_______________________________________________
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