NSLog();

I wrote about accessor methods in Cocoa before. One of the comments on that article implored me to check out Ali Ozer's talk at WWDC. I've done so, and I will now present what I've learned. I'm documenting this for myself, so if my explanation is brief, believe me when I say I understand what I've written. 😉

Properly written accessor methods allow you to write very straightforward code:

NSString *string = [myDoc title];
NSString *capString = [string capitalizedString];
[myDoc setTitle: capString];

The lines above ask for the document's title, capitalize that string, and set the capitalized version back as the new title. This could be done in one line:

[myDoc setTitle: [[myDoc title] capitalizedString]];

The "code just falls naturally." You get, you modify, you set. That's all there is to it. But how do we write the accessor methods to facilitate this ease? What is the "one true way" to write accessors (both setters and getters)? Some may think that this is okay:

- (void)setTitle:(NSString *)newTitle
{
    title = newTitle;
}

This of course will work fine if newTitle is going to stick around. If not, we need to fix it:

- (void)setTitle:(NSString *)newTitle
{
    title = [newTitle copy];
}

Though this fixes the problem with newTitle, it also leaks the old title. Leaks are bad. Let's fix that then:

- (void)setTitle:(NSString *)newTitle
{
    [title release];
    title = [newTitle copy];
}

This might crash if title and newTitle are the same. So we take the next logical step:

- (void)setTitle:(NSString *)newTitle
{
    if(title != newTitle)
    {
        [title release];
        title = [newTitle copy];
    }
}

That works. It fixes all of the problems we've encountered and it's a little more efficient. Here's another:

- (void)setTitle: (NSString *)newTitle
{
    [title autorelease];
    title = [newTitle copy];
}

This also works. We get rid of the original title "later." This works even if the two titles are the same. So both work, and every time both work, you've got to ask yourself a question: which is better? The one with release or autorelease? The answer depends on what the "get" method looks like and its usage pattern.

- (NSString *)title
{
    return title;
}

Is this one very "safe"? Look at this code:

NSString *string = [myDoc title];
[myDoc save];
[myLogFile recordAsSaved:string];

This illustrates why the getter and the setter have to be considered in tandem. In the code just above, the save function may change the title, releasing the old one in the process. Passing a released string to recordAsSaved: can't have good results. These are a bad pair:

- (NSString *)title
{
    return title;
}

- (void)setTitle:(NSString *)newTitle
{
    if(title != newTitle)
    {
        [title release];
        title = [newTitle copy];
    }
}

However, this pair is just fine:

// Style 1
- (NSString *)title
{
    return [[title retain] autorelease];
}

- (void)setTitle:(NSString *)newTitle
{
    if(title != newTitle)
    {
        [title release];
        title = [newTitle copy];
    }
}

Of course, there's still the other way to do this using the alternate set method:

// Style 2
- (NSString *)title
{
    return title;
}

- (void)setTitle:(NSString *)newTitle
{
    [title autorelease];
    title = [newTitle copy];
}

Effectively, the autorelease in the set method extends the lifetime of the object. So again we're down to the question "which is better?" We're smart, so we might also ask "why?"

The second pair is best if the performance of the "get" method is important. As you can see, it's just a return.

Typically, the first one is most appropriate. When you're dealing with threads, the first is safer because the returned object measures its lifetime in the thread in which it was called. Thus, the object hangs around nicely even if another thread has set a new value (releasing the old one, rendering your first thread's pointer useless).

This leaves us with one final question: copy or retain?

- (void)setTitle:(NSString *)newTitle
{
    [title autorelease];
    title = [newTitle retain];  // or copy ?
}

copy makes a brand new copy of the object while retain increments the retain count. The answer depends on whether you're interested in the actual value of the object or the object itself.

- (void)setTitle:(NSString *)newTitle
{
    [title autorelease];
    title = [newTitle retain];
}

str = [NSMutableString string];  // 1. Empty string
[str appendString: @"Hello"];    // 2. Modify str
[doc1 setTitle: str];            // 3. Set it as the title
[str appendString: @"World"];    // 4. Modify str further
[doc2 setTitle: str];            // 5. Set it as the title

In line four, suddenly doc1's title has changed. Thus, you'd want to use copy and not retain in this case. The document "owns" the title. It can set a new one, it can loan it to others, but it's title is "its own." Conversely, a number of examples exist which don't imply ownership:

• NSView's superview
• NSControl's target
• NSTableView's data source
• Delegates
• etc.

In each of these cases, it's okay to hold on to an object without retaining it. However, care must be taken when releasing the object. Think of it this way: when you release a view, you don't release the parent view. An example: if you give an object a delegate, and you release the delegate, you should tell the object to set its delegate to nil so it doesn't try to talk to it anymore.

So there we have it. We've learned about 256 combinations of setters and getters, about eight of which are appropriate some of the time, and about 72 of which are appropriate sometimes. I hope that clears it all up! Heh heh. 😀

Comments RSS