views:

142

answers:

2
@property (copy) NSString *name;
@property (copy) NSString *orbit;
@property (copy) NSNumber *mass;
@property float surfaceTemp;
@property float rotationSpeed;

Currently Have this

- (void)dealloc{
    [name release];
    name = nil;
    [orbit release];
    orbit = nil;
    [mass release];
    mass = nil;
    [super dealloc];
}

If I write this using Dot Notation (Objective-C 2.0) Is this right?

- (void)dealloc{
    self.name = nil;
    self.orbit = nil;
    self.mass = nil;
    [super dealloc];
}

gary

+10  A: 

It's bad practice to use your setter methods in -dealloc. Use [name release] instead.

Calling setters during -dealloc may have unintended consequences. If using KVO, setting properties may trigger other code to run causing side effects because your object has already started releasing instance variables. Even when not using KVO this may cause potential problems if your setter method relies on other instance variables that may have already been released.

(updated to reflect comments)

pix0r
I'd read this before, but only with respect to using them init, due to a potentially partially-initialized object. Why are they bad to use in dealloc?
nall
I've been searching for the reference, but to be honest I'm not sure why this is frowned upon. I just know that I was corrected because I used to do the same thing. The only thing I can think of is that your setter method may depend on other ivars or properties that have already been released.
pix0r
@nall if you have other objects using KVO to observe changes to that object's properties, then using the accessors in a dealloc can cause interesting things to happen (like the observers attempting to manipulate a partially destructed object). More info: http://stackoverflow.com/questions/1283419
Dave DeLong
Oh, duh. Same basic argument as init. Thx.
nall
Interesting, whats KVO if I might ask? But many thanks for your comments, I will take that as maybe its not such a good idea.
fuzzygoat
It's a mechanism for being notified when variables you specify change. More here: http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/KeyValueObserving/KeyValueObserving.html
nall
Not necessarily variables, but properties. The property can be backed by anything, including an instance variable, a key in a dictionary, a row in a database, or a file on disk. One of the purposes of accessors is to insulate users (and observers) of the property from your implementation of it.
Peter Hosey
A: 

In my experience self.name = nil does not do the same thing as [name release]; name = nil. My guess is that there is some code in the synthesized setter that avoids nil assignments, but YMMV. The properties I observed this on were also specified (nonatomic, retain) so you might see some differences there, too.

What is more, self. notation sends KVO notifications, so there is a performance penalty to be considered in this case as well.

fbrereto
Interesting, do you know if there is an overhead when using this notation in main() i.e. if you were accessing obj.name = @"mr happy"; as apposed to the more traditional [obj setName: @"mr happy"];
fuzzygoat
The use cases you mentioned are the equivalent.
fbrereto
are the equivalent as in they do add a performance penalty?
fuzzygoat
I'm not sure if they add a performance penalty- that would depend on the implementation. What I can tell you is that `self.x = ...` and `[self setX:...]` invoke the same code, which will incur the same penalty. Or did you have a different question in mind?
fbrereto
nope i'm good, thank you for the clarification.
fuzzygoat