Re: Retain/Release and Properties clarification
Re: Retain/Release and Properties clarification
- Subject: Re: Retain/Release and Properties clarification
- From: Charles Srstka <email@hidden>
- Date: Mon, 03 Oct 2011 13:43:10 -0500
On Oct 3, 2011, at 1:31 PM, Kyle Sluder wrote:
>> 1. Apple reserves the underscore prefix for their own use, so you could, at least theoretically, clash with a superclass ivar this way, and
>
> [snip]
>
>>
>> 3. If I use an ivar prefix that no one else uses (as far as I know), then I can make my class into a subclass of something from a publicly available framework without needing to worry about ivar name clashes.
>
> This only matters at compile time. If you have a class that subclasses
> a framework class, and you add an ivar named "_foo", later releases of
> the OS can add an ivar named "_foo" and your application will continue
> to run on the latest release without issue. (Well, on 32-bit Mac OS X,
> they can rename an existing ivar to "_foo" without issue; adding an
> ivar will trigger the Fragile Base Class problem.)
>
> On 32-bit Mac OS X, ivar accesses get translated into an offset.
> "self->_foo = 42" gets translated into something like "*(self + 18) =
> 42". On 64-bit Mac OS X and on iOS, ivar access is done indirectly via
> symbol. "self->_foo = 42" gets translated into something like "*(self
> + OBJC_IVAR_$_MyClass__foo) = 18". Neither of these methods actually
> cares what the ivar is named (the compiler could generate offset
> symbols based on the days of the week if it wanted to).
While that’s mostly true, there are a few exceptions, such as object_[gs]etInstanceVariable and that KVO automatic ivar thing. If Apple’s actually using those things internally somewhere (as I learned in a recent thread here, they do use object_setInstanceVariable for nib outlets if they’re declared as ivars rather than KVO properties), then who knows what effect it could have.
Besides, it’s always nice to save a few compile-time hassles, no?
Charles
_______________________________________________
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