In @mmalc's response to this question he states that "In general you should not use accessor methods in dealloc (or init)." Why does mmalc say this?
The only really reasons I can think of are performance and avoiding unknown side-effects of @dynamic setters.
Discussion?
It's basically a guideline to minimize the potential for bugs.
In this case there is the (possibility) that your setter/getter may inadvertently make direct or indirect assumptions about the state of the object. These assumptions could be a problem when the object is in the midst of being setup or destroyed.
For example in the code below the observer does not know that 'Example' is being destroyed and could assume that other properties, which have already been freed, are valid.
(You could argue that your object should remove all observers before tearing itself down, which would be good practice, and another guideline to prevent inadvertent problems).
@implementation Example
-(void) setFoo:(Foo*)foo
{
_foo = foo;
[_observer onPropertyChange:self object:foo];
}
-(void) dealloc
{
...
self.foo = nil;
}
@end
It is all about using idiomatically consistent code. If you pattern all of your code appropriately there are sets of rules that guarantee that using an accessor in init/dealloc is safe.
The big issue is that (as mmalc said) the code the sets up the properties default state should not go through an accessor because it leads to all sorts of nasty issues. The catch is that there is no reason init has to setup the default state of a property. For a number of reasons I have been moving to accessors that self initialize, like the simple example below:
- (NSMutableDictionary *) myMutableDict {
if (!myMutableDict) {
myMutableDict = [[NSMutableDictionary alloc] init];
}
return myMutableDict;
}
This style of property initialization allows one to defer a lot of init code that may not actually be necessary. In the above case init is not responsible for initing the properties state, and it is completely safe (even necessary) for one to use the accessors in the init method.
Admittedly this does impose additional restrictions on your code, for instance, subclasses with custom accessors for a property in the superclass must call the superclasses accessor, but those restrictions are not out of line with various other restrictions common in Cocoa.
You answered your own question:
The latter is particularly an issue if your class may be subclassed.
It's not clear, though, why this is addressed specifically at Objective-C 2 accessors? The same principles apply whether you use declared properties or write accessors yourself.
It may be that the setter has logic that should run or perhaps the implementation used an ivar with name different from the getter/setter or perhaps two ivars that need to be released and/or have their value set to nil. The only sure way is to call the setter. It is the setter's responsibility to be written in such a way that undesirable side effects do not occur when called during init or dealloc.
From "Cocoa Design Patterns", Buck, Yacktman, pp 115: "... there is no practical alternative to using accessors when you use synthesized instance variables with the modern Objective-C runtime or ..."
In fact, for a class that comes and goes rather often (like a detail view controller), you want to use the accessor in the init; otherwise, you could end up releasing a value in viewDidUnload that you try to access later (they show that in CS193P...)
You can create the same problems by NOT calling the setter when allocating/deallocating.
I don't think you can achieve anything by using retain/release directly in init/dealloc. You just change the set of possible bugs.
Everytime you have to think about the order of property allocation/deallocation.
