<i>3. When you type self.foo = bar, there is an implied retain. If you set a class variable without the "self," there is no implied retain.</i><p>No no no no no... That is absolutely incorrect. Only properties declared "retain" do that.<p><pre><code> @property (nonatomic, assign) NSObject *foo; // doesn't retain
@property (nonatomic, copy) NSObject *bar; // doesn't retain
@property (nonatomic, retain) NSObject *baz; // *does* retain
</code></pre>
(The 'nonatomic' isn't related to the retain/no-retain semantics, but most properties are declared nonatomic, as atomic properties have some locking overhead.)<p>On a side note, a discussion of iOS/Mac memory management isn't very useful if it doesn't talk about how autorelease pools work.
This:<p><pre><code> - (void) setFoo:(NSString*) bar {
[foo release];
foo = [bar retain];
}
</code></pre>
should be:<p><pre><code> - (void) setFoo:(NSString*) bar {
if(bar == foo)
return;
[foo release];
foo = [bar retain];
}
</code></pre>
so that you can do without crashing:<p><pre><code> obj.foo = obj.foo;</code></pre>
> 2. When you type "alloc" there is an implied retain.<p>It's not quite that simple. The official rule from Apple's Memory Management Programming Guide most succinctly states "You take ownership of an object if you create it using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message."
This article gives bad advice. If you use his examples your program will crash; see tylerc230's comment. Also, it does not follow generally accepted style practices, such as the lack of a space after a closing bracket [[like]this].
> “Typing self.foo releases and nils the variables.”
Yes, if it’s a retain or copy property.<p>> “Just typing foo = nil is a memory leak.”
Yes, if you had retained the object, but not if it were a weak reference. Admittedly, this is a semi-rare scenario.
it also help when you understand how the dot-notation works in objective-c... it's not like other languages where you are just accessing a member of an object.<p><pre><code> foo = object.bar;
is syntactic sugar for
foo = [object bar]; //where 'bar' is a method call
</code></pre>
and<p><pre><code> object.foo = bar;
is syntactic sugar for:
[object setFoo:bar];
</code></pre>
I dealt with a lot of goofy memory errors trying to figure out why using 'self.foo' and just 'foo' inside of a class acted differently. Now it makes much more sense.
Good article, though it kinda violates rule #1 of Cocoa memory management: don't try to summarize the rules, because you'll probably miss a subtlety. Link to the Apple docs instead.