This question already has answers here:
Difference between class property mVar and instance variable self.mVar
(3 answers)
Closed 9 years ago.
Really, why most of people use self.something for almost everything when code works without it?
for example:
-(void)viewDidLoad {
self.mylabel.text = [NSString stringWithFormat:#" %#", someVariable];
}
The code works the same way without self.
I have tried to see what happens without self and it always works.
Using self. means that you are using the getter/setter, and not using it means that you are accessing the instance variable directly.
This question has been treated a lot here, but summarising:
ALWAYS create a #property for every data member and use “self.name” to
access it throughout your class implementation. NEVER access your own
instance variables directly.
Properties enforce access restrictions (such as readonly)
Properties enforce memory management policy (strong, weak)
Properties provide the opportunity to transparently implement custom
setters and getters.
Properties with custom setters or getters can be used to enforce a
thread-safety strategy. Having a single way to access instance
variables increases code readability.
Source:
Best Practices fr Obj-C
Related
Say this is in my header file:
#interface AppDelegate : NSObject <NSApplicationDelegate>
#property (weak) IBOutlet NSSlider *slider;
- (void)doSomething;
#end
…and this is the *m:
#implementation AppDelegate
- (void) doSomething {[self.slider setFloatValue:0];}
#end
I'm new to Xcode and Objective C, and I would like to use and understand the modern “tools” presented by Apple in its documentation, namely ARC, or here more specifically the ability to skip #synthesize.
If I understood correctly, #property (weak) IBOutlet NSSlider *slider; does a few things for me, including:
creating an instance variable called _slider;
creating a getter named slider;
creating a setter named setSlider.
I've been doing C++ until now, so I see instance variables as the equivalent of what I am calling (rightly, I hope) members of my C++ classes, which I incidentally always call _member.
I understand that the whole point of encapsulation is that, if you're outside a given class, you have to use accessors to access those variables; they are private to you, so there's no way you can access them via _member even if you tried.
But, when I'm writing my *.m file of my class, _member means something. Back to my example, I think self.slider and _slider are equivalent. The latter comes naturally to mind first, as it saves a few character.
My question is: are the two absolutely equivalent?
I know this looks similar to this question, for example, but here’s a few reasons why I wanted to ask myself:
I don’t use #synthesize, so I’m really not the one creating _slider, and I wonder if this makes a difference (I believe this is a fairly recent improvement of ObjC, and most answers still refer to #synthesize);
it seems that on average, most conversations end up with “so, just use self.name”, but I don’t grasp if this is just a recommendation, a convention, of something more important (with an impact on, say, the performance);
similarly, some say you should only use _name in methods like dealloc and its friends; but I don’t write those thanks to ARC, so does this mean I should never use _name? If so, why?
I hope this justifies this post, I apologies if I missed a preexisting answer. Thanks in advance for your help.
self.name = compiles to [self setName:] this is very different then setting the variable directly.
One of the main reasons that using the default setter differs deals with key value observing often referred to as KVO. Using the setter will notify observers of changes, setting the _name directly will not.
Thats not to say you can't fire the events your self with willChangeValueForKey: and didChangeValueForKey:, but the default implementation will handle that for you. So as you say outside the class accessing them you have to use the property get/set but inside your class setting the variable directly will lose out on some notifications. I'm sure there are other differences this is the first that comes to mind.
Using the variable directly does have it's use cases, such as a custom property setter. I think the main take away is the dot syntax is a hidden function call to get/set.
https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/KeyValueObserving/Articles/KVOCompliance.html
Under basic circumstances, where you use the pre-made accessors, you could probably get away with using _slider or self.slider within your class interchangeably. They're not equivalent in how they compile necessarily, but the functionality could be said to be equivalent.
The bigger issue comes into play when you start overriding those accessors. When those accessors do more than just "getting" or "setting" a variable, such as accessing some sort dependency variable, accessing the instance variable directly bypasses that functionality that the accessors provide. In these cases, I don't think it can be said that the two are equivalent at all.
This question already has answers here:
Must every ivar be a property?
(4 answers)
Is the use of instance variables discouraged? [duplicate]
(1 answer)
Closed 9 years ago.
I am refactoring old code and wonder - with the advent of auto-synthesized properties and class extension, should most instance variables declarations be done in the form of properties as best practice?
Yes, best practice is to use properties, either in the interface file or implementation file class extension based on wether the property is by design public or private to the class.
It would depend on your coding style. Generally, put ivars that you want accessible to other classes as properties in the .h-file.
If you declare properties but leave #synthesize to the compiler, they will automatically be synthesized so that the property myInstanceVariable is internally called _myInstanceVariable.
Accessing _myInstanceVariable directly means that you will bypass any setters/getters which is sometimes desired internally in classes, especially when the getter creates an object.
However, often when I have internal simple ivars which don't require any setter/getter, I use the ivars directly in the class extension:
// MyClass.m
#import MyClass.h
#interface MyClass() {
BOOL _simpleInternalVariable;
NSUInteger _anotherSimpleInternalVariable;
}
#end
#implementation MyClass
- (void)someMethod
{
_simpleInternalVariable = YES;
_anotherSimpleInternalVariable = 4;
}
#end
This yields exactly the same result as #property BOOL simpleInternalVariable; except that you are sure that no setter/getter is automatically created by the compiler. I sometimes prefer this way because you can't write self.simpleInternalVariable. Writing self.ivar means a getter runs somewhere but you don't always know if it's a custom getter or synthesized getter. When writing _ivar, I always know that I'm dealing with the ivar directly.
For objects though, I always use properties both in the .h- and .m-files. I could theoretically do the same thing I did above with objects, but it's just a reflex from the non-ARC days where you always wanted the compiler to generate setters which retained/released objects.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How does an underscore in front of a variable in a cocoa objective-c class work?
Note: For the folks digging around trying to understand this, I figured-out the source of my confusion. In the .h, I had:
...
#interface myClass : parentClass {
className *variableName:
}
#property (strong, nonatomic) className *variableName;
...
This leads to self.variableName and _variableName being two distinct variables in the .m. What I needed was:
...
#interface myClass : parentClass {
className *_variableName:
}
#property (strong, nonatomic) className *variableName;
...
Then, in the class' .m, self.variableName and _variableName are equivalent
In brand-new, Xcode 4.5+, with ARC, targeting iOS 5.0+ project, is there a distinct advantage (runtime efficiency, speed, etc.) to using _variableName over self.variableName vs. the old-style #synthesize variableName?
My understanding is that Xcode 4.5+ will create a default accessor _variableName that is equivalent to self.variableName and the only reasons not to use #synthesize variableName is to avoid confusion between iVars and passed-in variables, correct?
To me, just using self.variableName to access an iVar seems the most straightforward and clear as to which variable you're looking for. Other than typing _ vs. self., is there an advantage to using _variableName?
My understanding is that Xcode 4.5+ will create a default accessor "_variableName" that is equivalent to self.variableName and the only reasons not to use "#synthesize variableName" is to avoid confusion between iVars and passed-in variables, correct?
In this case, _variableName isn't the accessor, it's an ivar that is automatically generated by the compiler and used in the automatically #synthesized setters and getters. Generally, it is considered best to use accessors whenever possible (i.e. self.variableName) so that things like key-value observation and bindings work for that property.
When you access an ivar directly, it is accessed via direct memory access, the same way you would access data in a struct. It simply takes the pointer for the object that owns the ivar, offsets the memory address and attempts to read or write to the memory at that location. Using dot notation (self.variableName) calls the accessor methods to set or get that property and can do a number of different things along the way, such as:
1) Locking: If the property is going to be used in multiple threads and is an atomic property, the runtime will automatically do some locking to make sure that the property is not accessed at the same time from multiple threads. If your object is not meant to be used on multiple threads, you can give the nonatomic hint in your property declaration so that the synthesized accessors skip the locking.
2) Key-Value Notifications: The default setters for properties call -willChangeValueForKey: and -didChangeValueForKey:, which sends out notifications when the property is changed. This is necessary for anything to update properly if bindings are used, and for any other key-value observation.
3) Custom accessor behavior: If you end up writing your own setters and getters, any custom stuff that you implement within those.
Technically, accessing the ivar directly is faster than using accessors, but there are very few situations in which it will make a significant performance difference, and would probably be a case of premature optimization. Even if you don't feel like you would be using the benefits listed above right away, it's probably better to use the accessors anyway so that if you decide later on you need some of that functionality, you don't have to change every instance of accessing that variable (and possibly be creating unexpected new bugs in the process).
In addition, if you are accessing ivars directly and end up refactoring your class into categories or subclasses, it gets messy because you usually have to declare the ivar as a #protected variable. You wouldn't have to do this if you are using the accessors.
Generally, I try to only access the ivars directly in init, dealloc, and the property's accessor. A lot of engineers go by this rule of thumb because sometimes the custom stuff that happens in accessors can cause unexpected behavior while the object is init'ing or dealloc'ing. For example, if anything in the accessors causes something to retain or release your object or even form a zeroing weak reference to it, it will cause a crash if used in dealloc.
In the latest Xcode #synthesize is optional. By default, omitting #synthesize is the same as writing
#synthesize someName = _someName;
The only reason to use #synthesize is to rename the instance variable created to store the value of the property, for example
#synthesize someName = someSpecialName;
When you use self.variableName to access a variable, you go through a property, which is a short method that accesses the instance variable for you. Although the method dispatch is very fast, it may perform additional services for you, such as synchronizing the access to the variable (this is the case when you specify atomic or do not specify nonatomic in the property declaration). In cases like that, the access through self.variableName will be somewhat slower. If done in a tight loop, this could potentially make a difference. That is why you sometimes want to access the underlying instance variable directly by using _variableName.
This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
When to access properties with 'self'
In Objective-C on iOS, what is the (style) difference between “self.foo” and “foo” when using synthesized getters?
For example sake, I have a #property named obj and I #synthesize it. So when do I need to use [self.obj message] vs [obj message] in my implementation class.
Using self, the getter method will be called. Thus, any additional logic in this getter method is executed. This is especially useful when instance variables are lazy loaded through their getters.
I myself try to use self most of the time. Lazy loading is just an example, another thing is that with self, subclasses may override the getter to get different results.
Using self to set a variable is even more useful. It will trigger KVO notifications and handle memory management automatically (when properly implemented, of course)
Here are two great tutorials that cover this issue well:
Understanding your (Objective-C) self
When to use properties & dot notation
When synthesize a property, the compiler declare a related ivar for you, in default, the ivar is the same as property name. I recommend use self.obj always to keep code cleaner, and avoid some potential bugs.
And I suggest you follow the good practice from Apple, #synthesize obj=_obj, the ivar will become _obj, when you mean to use property, this style force you to write self.obj, directly call obj will be error since the ivar is _obj.
Edit: automatically creating ivar for property is only in modern Objective-C runtime, it's safe in iOS SDK 4.0 and Mac OS X 10.6 above.
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html%23//apple_ref/doc/uid/TP30001163-CH17-SW1
For #synthesize to work in the legacy
runtime, you must either provide an
instance variable with the same name
and compatible type of the property or
specify another existing instance
variable in the #synthesize statement.
With the modern runtime, if you do not
provide an instance variable, the
compiler adds one for you.
In the future, please search the site. You'll often find that the exact question you're asking has been asked before:
difference between accessing a property via "propertyname" versus "self.propertyname" in objective-c?
When to access properties with 'self'
self.variable and variable difference
Objective-C: When to call self.myObject vs just calling myObject
iVar property, access via self?
Should I Use self Keyword (Properties) In The Implementation?
In Objective-C on iOS, what is the (style) difference between "self.foo" and "foo" when using synthesized getters?
When to use self on class properties?
... etc.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Properties and Instance Variables in Objective-C 2.0
If I create a #property in a header file and the #synthesize it, everything seems to work fine, even if the item is not also declared as an instance variable. So why does all the example code I see declare items as both properties and instance variables?
The #property command in Objective-C 2.0 will automatically generate the instance variable for you if you have not done so. This is a shortcut introduced to limit the amount of repetitive code you have to write.
Only declare the iVar's if:
Need to directly access them for some advanced reason (i.e. you want to manage the memory yourself)
You want subclasses to be able to access the iVars (if you don't specify them at all, or specify them as #private, then subclasses will be forced to use your #synthesized accessor methods.)
You want your iVar to have a different name to the property itself, in which case use #synthesize myProperty = myInstanceVariable_
NOTE: If you plan to run your code on older devices or compile it with older versions, you will need to declare iVars.
No, you dont.
But the autogenerated methods will try to access the instance variables, so you have to implement the setter and the getter for the property you have added.
See Vladimirs comment with the following link:
Properties and Instance Variables in Objective-C 2.0