Trying to understand when it is needed to prepend object names with self.
Sometimes I am able to reference objects that I have initialized without adding self. and other times my code won't work without adding it.
Can someone explain when I should definitely use the self. reference and when it is not needed?
Whenever you use self.blah or someObject.blah, you are using a "property". Properties are an easy way to call certain methods to get and set the value of a variable inside the class (an instance variable.)
In other words, when you say self.blah = true, it's shorthand for [self setBlah:true]. You either need to write the setBlah method yourself, or use @synthesize to get the compiler to write them for you. The setBlah method may copy the object you give it, or retain it, or simply assign it, depending on the settings you chose for the property.
When you simply say blah=true, you are not using the property, and you are not calling the setBlah method. You are simply changing the value of the variable, with no retain or object copy or any other tricks.
If you look up "properties" in your favorite book or reference you'll find out more.
Quick addendum: When you define a property the critical places you will want to use self.property ( to my knowledge ) are : IF the property variable is an object pointer ( not a primative like int or BOOL ) and you are setting the value.
Code:
@property (nonatomic, readwrite) int someValue;
@property (nonatomic, retain) UIView *someView;
// these two are equivalent
someValue = 3;
self.someValue = 3;
// these two are NOT
someView = newView;
self.someView = newView; // use this one
// shouldn't matter when *getting* the value
newView = someView;
newView = self.someView;
If you look into a basic tutorial on writing properties yourself it should become fairly apparent what happens behind the scenes when you use the @property/@synthesize statements, which should make it more obvious which cases you need to use self ( to go through the property accessors ).
If you read my post, you'll see that I am absolutely NOT indicating that they are always equivalent. The example provided was for a primative ivar that had it's @property option set to readwrite.
[edit]
Again, you will want to use the self prefix when you want to SET a value for an object variable who's @property declaration indicated extra memory notations ( retain / copy ). In other circumstances it's syntactical fluff as far as I'm aware.
It's true that prefixing with self calls the setter method. But the point is that in cases where no retain/copy/release is being performed in the setter ( IE when you specify assign, readwrite, etc for nonatomic properties ) that the two are functionally performing the same thing behind the scenes.
It's true that prefixing with self calls the setter method. But the point is that in cases where no retain/copy/release is being performed in the setter ( IE when you specify assign, readwrite, etc for nonatomic properties ) that the two are functionally performing the same thing behind the scenes.
Usually but not always; I think jtara's point is that there are other situations where the setter and getter might do something other than directly set the ivar.
For example, I might have two properties, angleInRadians and angleInDegrees, but only one ivar for angle, and write getters and setters to modify that ivar. In that case, "self.angleInRadians = blah" would be correct, and just "angleInRadians = blah" would be an error.
Totally true in the case where you write your own properties. I was refering only to the cases where you use the @property / @synthesize method for generating the accessors. =)
If you're going to use properties, good programming practice dictates that you always go through your accessor methods. The slightly more verbose syntax makes your code more readable by clearly distinguishing and identifying the scope of public properties from instance (which may be private) or local variables. The additional overhead is also negligible unless you're in a tight loop, in which case you can use a local variable inside the loop and accessor methods around it.
Always using accessor methods can help you with debugging. You can monitor a property which is acting strangely by overriding the synthesized accessors, testing for invalid values and breaking as necessary. This may be easier than using watchpoints in gdb for complex cases.
If you always go through accessor methods, your code will be ready for interesting KVC technologies that make Cocoa so powerful, such as KVO, object archiving, and eventually Core Data and Cocoa Bindings (hopefully). If you directly access your properties, you bypass the runtime mechanism for hooking into these technologies.
Quote:
Originally Posted by exorcyze
It's true that prefixing with self calls the setter method. But the point is that in cases where no retain/copy/release is being performed in the setter ( IE when you specify assign, readwrite, etc for nonatomic properties ) that the two are functionally performing the same thing behind the scenes.
Note that this will not work if you're using KVO, say, to keep your UI in sync with your model objects, even for simple properties such as assigned scalars. This is important because you have no control over who may want to observe a property you've declared, which is public by definition. Being a good citizen means always going through the accessor so any observers can be properly notified. This isn't an issue for code you entirely own, but if you ever plan to release it as part of a framework or collaborate with others, it's best to follow good habits from the start.
When to use "self.objectName" or just "objectName"
Linear Mode
