Is there any problem using self.property = nil in dealloc?

Question

I know declared property generates accessor method which is someway just syntax sugar.

I found quite a lot people use self.property = nil in their dealloc method.

1) In Apple's Memory Management document, p23 It says:

The only places you shouldn’t use accessor methods to set an instance variable are in init methods and dealloc.

why shouldn't?

2) In apple's Objective-C 2.0, p74

Declared properties fundamentally take the place of accessor method declarations; when you synthesize a property, the compiler only creates any absent accessor methods. There is no direct interaction with the dealloc method—properties are not automatically released for you. Declared properties do, however, provide a useful way to cross-check the implementation of your dealloc method: you can look for all the property declarations in your header file and make sure that object properties not marked assign are released, and those marked assign are not released.

Note: Typically in a dealloc method you should release object instance variables directly (rather than invoking a set accessor and passing nil as the parameter), as illustrated in this example:

- (void)dealloc { [property release]; [super dealloc]; }

If you are using the modern runtime and synthesizing the instance variable, however, you cannot access the instance variable directly, so you must invoke the accessor method:

- (void)dealloc { [self setProperty:nil]; [super dealloc]; }

What does the note mean?

I found [property release]; and [self setProperty:nil]; both work.

Quail

related: #5933177 – Nedi

Answer 1

Setting a property can lead to notifications being sent to other objects that are observing that property. That could in turn lead to those objects attempting to do something further with your object. If you are in the middle of deallocating, this is probably not what you want to happen. So in general it is safer to release the relevant instance variable directly.

Note that this sort of problem will only arise in certain cases, so it is often perfectly possible to write code using self.property=nil in dealloc and for everything to work out fine. It's just not best practice.

In the Objective-C "modern runtime", it is possible to declare properties without ever specifying the ivar. The runtime will synthesise the storage to go along with the synthesised accessors. In this case you cannot release the ivar directly because as far as your code is concerned there isn't one. So you have no choice but to go the self.property=nil route.

Fearnought

Two things, the synthesized storage is still accessible through the name of the property. @synthesize will provide the ivar there. 2nd, if you still have objects trying to observe you when you're deallocing, there are larger issues at work. – Siracusa

There used to be a bug under which the synthesized ivar was unavailable directly. But that was a compiler bug, and has been fixed for quite a while now. – Gerri

@Joshua Granted, but they may not be your issues. The point of any such defensive programming convention is surely just to avoid adding further to the confusion. – Fearnought

Cocoa convention is to fail fast on programmer error though. With NSZombies this is a very easy issue to track. – Siracusa

@Joshua Well, OK. But are you suggesting that following the "no property assignment in dealloc" advice is actually bad practice that will mask bugs? – Fearnought

Some people say that nilling your properties at all can hide bugs, I disagree with that one. But yes, assuming everything is handled properly, self.prop = nil is perfectly valid. – Siracusa

Not that I'm advocating carelessness, but doesn't self.prop = nil guard against inadvertently over-releasing? – Obituary