Objective-C: When to call self.myObject vs just calling myObject

Question

This little bit of syntax has been a bit of a confusion for me in Objective-C.

When should I call self.myObject vs just calling myObject?

It seems redundant however they are not interchangeable.

Would someone please enlighten me?

Answer 1

If you're just accessing them, there's not much reason to use self.member. If you're doing assignment, it's good if you're doing more than the simple @property (assign) parameter--for instance, retain, copy, etc, so it can save on code you're writing. An example:

myObject = anotherObject;
self.myObject = anotherObject;

The second choice will ensure that you're actually assigning the object the way you want (getting a copy, increasing the retain count, etc.). It's no different from [self setMyObject:anotherObject].

Since the dot-notation gets substituted for a message by the compiler (similar to how x[5] becomes *(x + 5*sizeof(x)) in regular array work), there's no overhead or extra efficiency in using dot-notation over regular messages.

Answer 2

Hrm, I cannot say that I agree with Mark or Cinder6.

Well, I agree in the first part. :-) self.foo is invoking the -foo method. Plain foo is accessing the foo ivar.

In most circumstances you should always go through your methods. They're there to abstract you away from the actual storage, and away from any other behavior that might be necessary. Think about what happens if you later subclassed your class. For the most part you want to be calling your own public methods in the places where you access the functionality they cover.

The exception is in object init and teardown, and within property accessors themselves when you don't synthesize them. During object init and teardown, you do not want to invoke subclass implementations of methods, because those methods should not have to deal with your object in its partially set up state.

Answer 3

You should almost never call property accessors from within the implementation of the same class. Instance methods of the class have convenient access to the internal state, so it usually makes sense to access that state directly.

If you're using synthesized accesors, then calling them just adds (probably) unnecessary overhead. If the accessors have a more complicated implementation, then you're just obscuring the purpose of the code.

Finally, some folks who are new to Objective-C use the self.property syntax and synthesized accessors to try to avoid having to understand Cocoa memory management. You really do need to learn how it works, so trying to avoid doing so is counter-productive.

Answer 4

If you're using Core Data, you should essentially always use the accessors, since some properties may not be loaded from the persistent store until needed. (Assuming you're using a SQLite store, anyway.)

If you're not using Core Data, you're generally safe to just use myObject directly if you're only reading the value. If you're modifying the value of myObject, you need to use the accessors in order to make sure that any other objects observing the value of that property are properly notified. In other words:

// Not changing the value of myObject, so no accessor needed
[someMutableArray addObject:myObject];  

// Changes the value, so you need to use the accessor
self.myObject = newObject;     
[self setMyObject:newObject];  // Exactly identical to the previous line.

In general, though, there's very little overhead; I prefer to always use the accessors, even within the same object. (Of course, there's the argument over using them in initializers, but that's a separate issue.)