Re: Outlets / IBOutlet declarations (was Re: InterfaceBuilder &Wiring Objects)
Re: Outlets / IBOutlet declarations (was Re: InterfaceBuilder &Wiring Objects)
- Subject: Re: Outlets / IBOutlet declarations (was Re: InterfaceBuilder &Wiring Objects)
- From: Roland King <email@hidden>
- Date: Thu, 20 Nov 2008 08:28:58 +0800
Jeff Laing wrote:
There's no difference between setting through a property, and setting
through a plain old setter method. That said, it's up to you to decide
if you want to go with the official recommendation or not. If you
think that you have enough control over the implementation of your
accessor methods, you might choose to still use them.
The question has been related to "best practices", which is why I'm
pursuing it.
As to 'control over the implementation of your accessors', if people use
@synthesize (thus taking whatever the compiler gives them) and/or have
bindings (or whatever it is) sneaking additional KVO/C stuff in over the
top of their accessors, how much information do they actually *have*
about their accessors to make an informed choice?
I think if you're talking about your own instance variables which you
are declaring and synthesizing, you have enough information to decide if
it's safe to call your property accessors in dealloc or not. If you're
inheriting a property from above .. well you shouldn't have to care
about it as someone else is worrying about it in their dealloc.
One case in which I use the setter in my dealloc code is is when I have
a custom setter which does something, like it tears down KVO or turns
off a timer or otherwise cleans up, I fix the setFoo: method to be the
one place I do that work, and then I use [ bar setFoo:nil ] in the
dealloc(). Given I do that, I think I should probably just use
setBlah:nill for all my dealloc() needs for consistency as I like to
have one way of doing things if possible.
The only 'problem' with this I can see is that it triggers KVO if
someone's observing me, but they shouldn't be, I'm being dealloc'ed and
if someone's observing me and they've allowed me to be fully released,
that's their bug.
_______________________________________________
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