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?
Prefixing property names with an underscore in Objective C
When we declare a property and then synthesize it like this for example:
#synthesize name = _name;
So, the _name is an instance variable for the name property we are gonna use in the following implementation.
My question is why we need this ivar and what would happen if i didn't create the _name ivar?
Thank you.
My understanding is that there is a default ivar name, which is the same as the property name. One of the reasons for specifying your own, with an underscore, is to eliminate ambiguity in your setter:
-(void) setFoo:(id) foo {
// here, foo should ONLY refer to the passed-in var
// If your ivar is the same, it is ambiguous.
// If your ivar is _foo, then there is clarity.
}
Related
This question already has answers here:
Under what conditions is #synthesize automatic in Objective-c?
(5 answers)
Closed 7 years ago.
I've only been in the Objective-C & Cocoa world for a year, so I wasn't around when properties weren't automatically synthesized
Whenever I create new classes in our project, I can declare #property BOOL testFlag without declaring an instance variable. Then, in the implementation, I could either call self.testFlag, [self testFlag], [self setTestFlag:NO]. But, I could also call _testFlag. I always assumed because properties are automatically synthesized with instance variables, that's why I can just append a "_" underscore before the property name to directly access the instance variable.
However, I have been refactoring really old files, that clearly were created before auto-synthesizing was a thing
So now in the header, I'd see something like this:
#interface testClass
{
BOOL _testFlag
}
#property BOOL testFlag;
In the implementation, there could be a custom setter/getter:
#implementation testClass
#synthesize testFlag = _testFlag;
-(void)setTestFlag:(BOOL)testFlag
{
_testFlag = testFlag;
}
-(BOOL)testFlag
{
return _testFlag;
}
But I thought because of auto-synthesizing, I could remove the _testFlag declaration in the header, and I could remove the #synthesize in the implementation. But when I do this, there are just a truck ton of errors; wherever somebody was directly trying to access the ivar _testFlag. (This actually includes the custom getter/setter above ^^, too)
Is there perhaps something I am missing with the project settings that prevent this old file from generating an implied instance variable for properties?
Remove the getter and setter to have automatic synthesis of the backing variable. When you supply both for the property, the assumption is that you're going to look after storage yourself.
This question already has answers here:
Good practice for disambiguating argument names versus instance variable names in Objective-C
(3 answers)
Closed 9 years ago.
I have been learning and using Objective-C for quite some time now (it also kind of was my first OOP language) and I finally would like to know how to correctly name synthesized properties.
Let's take the following scenario:
I have got a property called someVariable.
#property (nonatomic, retain) NSString *someVariable;
and synthesize it
#synthesize someVariable;
How would the custom setter look like conventionally ?
1)
I would go ahead and say something like
-(void)setSomeVariable:(NSString *)someVar{
//input parameter MAY sound/look foreign due to the difference to the property
someVariable = someVar;
}
2) (illegal)
But I would like to name the formal parameter just like the property for the sake of readability and convenience. More like in Java like this:
-(void)setSomeVariable:(NSString *)someVariable{
//obviously illegal because this would call the setter over and over again
self.someVariable = someVariable;
}
3) (unconventional)
and according to what I have been reading in the past this
#synthesize someVariable = _someVariable;
is said to be unconventional and not supposed to be used.
So, am I correct in concluding that the way I have been doing it until now, is the only way to create a custom setter ?
3) is not unconventional, it's exactly what the compiler does if you don't provide the #synthesize statement.
This means that, without the #synthesize statement and the ivar declaration, you have an implicit ivar named _someVariable, and a custom setter would usually have a parameter named someVariable
-(void)setSomeVariable:(NSString *)someVariable {
_someVariable = someVariable;
}
Also note that providing custom setter and getter methods for a particular property indicates to the Xcode compiler to not provide the implicit ivar (here _someVariable). In the case of readonly properties, the same if true if you provide just the getter method.
WWDC 2012 session 405 provides a lot of details around Objective-C constructs for modern versions of the compiler.
EDIT
As H2CO3 has suggested in his answer, the code I wrote assumes you're using ARC. If you are using MRC, the setter method would rather be :
-(void)setSomeVariable:(NSString *)someVariable {
[someVariable retain];
[_someVariable release];
_someVariable = someVariable;
}
This question already has answers here:
What does #synthesize window=_window do?
(3 answers)
Closed 9 years ago.
I'm just starting to use Objective-C and I need to clarify something
When I #synthesize a #property, it is common convention to do the following:
#interface Class : ParentClass
#property propertyName
#end
#implementation
#synthesize propertyName = _propertyName;
#end
I've seen plenty of questions and answers suggesting that "_propertyName" is widely accepted as the "correct" way to synthesize properties. However, does it serve ANY purpose? Or is it merely to increase readability and identify instance variables?
It makes it so that if you accidentally leave off "self." you get a nice compiler error instead of silently not having your methods called.
From http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html
You Can Customize Synthesized Instance Variable Names
As mentioned earlier, the default behavior for a writeable property is
to use an instance variable called _propertyName.
If you wish to use a different name for the instance variable, you
need to direct the compiler to synthesize the variable using the
following syntax in your implementation:
#implementation YourClass #synthesize propertyName =
instanceVariableName; ... #end
Also:
Note: The compiler will automatically synthesize an instance variable
in all situations where it’s also synthesizing at least one accessor
method. If you implement both a getter and a setter for a readwrite
property, or a getter for a readonly property, the compiler will
assume that you are taking control over the property implementation
and won’t synthesize an instance variable automatically. If you still
need an instance variable, you’ll need to request that one be
synthesized: #synthesize property = _property;
By doing this the generated accessor actually got to know which variable(iVar) to use.
Yea, It increases the readability & also separates the private & public variables to understand & use. Private variable of Class generally written in "propertyName" format.You can say it is a coding convention where Private Variable Names use '' as prefix and Public Variables or Property Names are lowerCamelCase.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Prefixing property names with an underscore in Objective C
When synthesizing properties I found out that someone is doing:
#synthesize myVar = _myVar;
what is "_myVar" and which is the difference with simply doing :
#synthesize myVar;
Lastly when I should prefer the first solution to the last one?
Thanks
Luca
What _myVar really is in your example, is the name of the ivar that is backing your property. By default, when you synthesize a property, an ivar of the same name is created for you. So, you can use your property to set your ivar through setter/getter or the _myVar to directly access your variable (bypassing KVC/KVO of course).
EDIT:
From Apple's Coding Guidelines for Cocoa
...In many cases, when you use a declared property you also synthesize
a corresponding instance variable.
Make sure the name of the instance variable concisely describes the
attribute stored. Usually, you should not access instance variables
directly, instead you should use accessor methods (you do access
instance variables directly in init and dealloc methods). To help to
signal this, prefix instance variable names with an underscore (_)...
If you want to use some existing data member in setter and getter then it can be specify like that.
e.g. #synthesize personName=pName;
by this we can use pName instead of personName as per our convenience.
It the name of the private variable.
Se my answer on an other post: answer
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?
It is not fully clear to me (other than for readability of the code), why you wanna create an internal variable with an underscore prefix when you create the property.
Since everything is handled internally, why bother to do so, since we do not add any code to the getter and setter?
And even if i gotta add some code to the getter or setter, i do not see why i cannot just do the check on myvar instead than having to check _myvar and then assign it to myvar.
Can anyone give me some explanation, other than "do it because that's what everyone does ?" I would like to understand the whole reason behind this practice (that seems to be pretty common even if there is no custom code for the getter and setter).
Thanks!
I've wondered this many times myself. Interested in other people's answer, but one reason I've found is that it forces you to notice if you're accessing the ivar directly when you should be using the getter/setter.
self.myvar = #"blah"; and _myvar = #"blah";
vs
self.myvar = #"blah"; and myvar = #"blah";
It's easy to leave the self. out by accident... it's a lot harder to put the _ in by accident.
An Objective-C property usually has a backing instance variable (I guess you know the difference between a property and an instance variable).
The property may have a different name than the instance variable.
For instance, you may have an instance variable named x, with a property named y.
You can synthesize the y property to the x variable using:
#synthesize y = x;
Now about the underscore.
It's a common practice to use an underscore prefix for instance variables, to prevent naming collisions, or compiler warnings (shadowed variable), when having for instance a method argument with the same name as an instance variable.
The underscore prefix also makes clear that you are referring to an instance variable.
By using the underscore prefix for instance variables, you're free to use the name without the underscore in method's arguments, stack variables, etc.
But when using a property, you usually don't want the user to write an underscore.
So you usually have an x property for an _x instance variable.
This is why you write:
#synthesize x = _x;
Let's take an example:
#interface Test: NSObject
{
int x;
}
#property( readonly ) int x;
#end
This is quite common... But now imagine this in the implementation:
- ( id )initWithX: ( int )x
{}
We have are a naming collision.
Inside our method, x will refer to the method's argument. And there is no pretty way to access the x instance variable.
Depending on your compiler's warning flags, this may also generate a warning (-Wshadow).
If you use an underscore prefix for your instance variable, everything is just simple:
- ( id )initWithX: ( int )x
{
if( ( self = [ super init ] ) )
{
_x = x;
}
return self;
}
No conflict, no naming collision, improved reading... Just a nice way...
When using a property of self, it's easy to forget the "self":
[self.field doSomething]; // what you probably want
[self setField:someObject]; // also kosher
self.field = someObject; // ditto, although not my style
vs.
[field doSomething] // might work.. but will bite you eventually
field = someObject; // almost certainly wrong anywhere outside a custom setter
If the property and the ivar are named identically, the latter cases will compile without complaint and appear to work... until they don't, and you get a weird hard-to-reproduce edge case bug.
If the ivar has a slightly different name, say with a trailing _ appended, the compiler will stop you and make you explicitly decide: do I want to refer to the property here, or the ivar directly?
(All that said, I am lazy and often do #synthesize field;, and replace it later with #synthesize field = field_; when I actually need the distinct ivar, say when it's custom-setter-writing time.)