Re: How To Increment CALayer Retain Count?
Re: How To Increment CALayer Retain Count?
- Subject: Re: How To Increment CALayer Retain Count?
- From: Quincey Morris <email@hidden>
- Date: Sun, 10 Apr 2011 02:14:50 -0700
On Apr 9, 2011, at 23:17, Jeffrey Walton wrote:
> The problem was prefixing the various IBOutlets with "self.". To add
> insult to injury, I added "self." to nearly all interface variables to
> ensure disambiguation when I first encountered EXC_BAD_ACCESS.
>
> According to Hillegass, "self" is equivalent to "this". So I'm not
> sure what is going on with the dot operator (or I don't have the
> correct understanding in Obj C).
I'm not sure if you got your full answer yet, so I'm going to try to lay this out in some detail:
-- Your problem was that you used those release macros incorrectly. They were solely for instance variables, and were simply wrong if you specified property references.
-- It's not entirely your fault -- IMO those are terrible, terrible macros, because they're terribly, terribly dangerous. If you know how to use them safely, you don't need them at all. If you don't know how to use them safely, you shouldn't use them at all. :)
-- Your conceptual confusion is common amongst developers new to Objective-C (and TBH quite a lot of long-time ones, too), but it's vital that it's cleared up if you're going to continue writing Objective-C code without tearing your hair out.
Properties are *behavior* of a class, not *things*. They *have* values, and "get" and "set" values, whatever that means in the property's API, but don't reveal to the outside world anything about how (or if) those values are stored by the class's implementation.
Instance variables are things, not behavior. They are, potentially, *backing storage* for properties. As such, they're an implementation detail. A property may, as implementation detail, use a same-named instance variable, or a different-named instance variable, or multiple instances variables, or no instance variables, as its backing storage. Clients of the class don't care. Only the implementor of the class should care.
As class implementor, it's best to think of the ivar name as something completely different from the property name. If you had, you'd never have been tempted to 'add "self." to nearly all interface variables'.
Once you get this distinction clear, things should fall into place.
Being uncertain about this isn't entirely your fault either***. @synthesize's default behavior (assuming or creating a same-named instance variable) is an inducement to confuse properties with ivars.
Also, though this may not have been in play in this case, there's a really confusing shortcut in KVC property access that conflates properties with ivars, as a "help" to the developer. You should routinely disable it by adding + (BOOL) accessInstanceVariablesDirectly {return NO;} to all your classes.
Finally, the general practice is now to avoid using property getters and setters in 'init' and 'dealloc' methods. There has historically been some controversy over this question, but under normal circumstances it's the instance variables you want to manage in those methods, not the property values.
HTH
*** You aren't alone. For a while, the gcc 4.2 compiler itself had a bug where it confused ivars and properties of the same name.
_______________________________________________
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