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?
Why rename synthesized properties in iOS with leading underscores?
I am a green hand in iOS programming.
I always see such a statement in other's code
#synthesize textNoteOrLink = _textNoteOrLink;
What is the meaning of the underline anyway? Can we just 'textNoteOrLink' in that case.
Yes you can just write textNoteOrLink.
Many developers put an underscore at the start of instance variable names (#synthesizing a property actually adds an ivar for that property) to avoid accidentally using the ivars instead of the property, bypassing setters and getters.
IMHO it's a good thing to do, but if you don't like it, just don't use it, but be cautions not to confuse properties and ivars.
Related
This question already has answers here:
How does an underscore in front of a variable in a cocoa objective-c class work?
(9 answers)
Closed 9 years ago.
being relative new to programming iOS apps, I find it very useful to start off with some sample code.
Hence, I ended up with a .m file, that starts with some lines that look like
#synthesize valueOne= _valueOne;
I noticed that having such a syntax makes it impossible to programmatically set properties of valueOne, for instance doing things like
valueOne.tag = 3
Therefore, for my own purposes, I have outcommented the "=_valueOne" part, without any noticeable harm to the functionality of the code.
What is the significance of such syntax, and what has been the consideration of the author of my sample code to use it?
Thanks in advance
This syntax is synthesizing the backing ivar for valueOne under the name _valueOne. You can simply write your code to look like
_valueOne.tag = 3;
That said, it's generally considered better to use the property accessors whenever possible, so you'd typically write this as
self.valueOne.tag = 3;
The notable exceptions to this are when you're in -init, -dealloc, or your own custom getter/setter you still want to use the ivar directly.
Using a prefixed underscore on ivar names is generally considered good practice, because it means if you write valueOne.tag = 3; and you meant to use the property, you get a compiler error instead of silently using the ivar. If you intend to use the ivar, you can just use the underscore prefix, as _valueOne.tag = 3;.
This is such a common practice that the auto-synthesis behavior of modern clang will use the leading-underscore style for ivars. This means that if you delete the #synthesize line entirely, it will behave as though you had #synthesize valueOne = _valueOne;.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What's the best way to use Obj-C 2.0 Properties with mutable objects, such as NSMutableArray?
Please excuse my poor English :)
In Objective C, the 'copy' qualifier doesn't retain the mutability. We have to make a property 'strong' or provide a setter ourselves.
I just want to know why the 'mutablecopy' qualifier is not provided. Any specific reason or design tradeoffs ?
Why no 'mutablecopy'?
Because making a mutable copy actually has deep and subtle meaning that makes it nontrivial. As well, you pretty much never want an objects internal storage to be externally mutable.
Also, if properties were to support mutable copy, there would need to be a version for the setter and one for the getter as each has a very different potential role (if you really did want a mutable property, you might want a mutable copying setter and normal retain getter. Or the other way around.).
None of this addresses the even nastier issue of deep versus shallow mutable copy.
This question already has answers here:
Is there any reason to declare ivars if you're using properties exclusively in Objective-C?
(4 answers)
Closed 8 years ago.
If an ivar is to be used globally within the class, but will never be accessed by other classes, are we still supposed to use properties?
It is generally a good idea, as the generated accessors will take care of things like memory management and KVO for you. You can put the property in a class extension so other classes can't use it.
For me, it depends on what the instance variable will be used for.
If it's an object representing some data, then I will always use a property.
If it's just a simple BOOL for some internal bookkeeping by a couple of methods in the class, then I won't create a property for it.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Underscore prefix on property name?
What does this mean? #synthesize window=_window; I know that in general it means that 'some class' has a window, but why use _window instead of just window? Is this a namespace thing?
I'll give a go at describing this programming convention in basic English.
It is a very common convention in other languages to name member variables with a preceding m, m_, or _ to distinguish them from locally declared variables and to signify that they should have accessors written, if necessary (no classInstance.m_Variable = 5).
If an Objective-C programmer declares ivars following this convention (and they should) and uses the basic syntax #synthesize _window; then the usage for the property becomes somewhat ugly: classInstance._window = myWindow or [classInstance set_window:myWindow]. Using the syntax #synthesize window=_window; allows the Obj-C programmer to utilize a popular programming standard (preceding ivars with _) while simultaneously having property accessors that use the Apple standard classInstance.window = myWindow and [classInstance setWindow:myWindow].
This is a very common thing to do in iOS programming/objective-C, it has to do with ivars. For more information you can read here:
Why rename synthesized properties in iOS with leading underscores?
How does an underscore in front of a variable in a cocoa objective-c class work?
Based on my experience in having this habit in my code, it helps me to accidentally writing window when you mean self.window and vice-versa (doesn't have to be window, but any other variables as well)
short answer is: the underscore is just a convention useful to stress the fact that class variables are "private" to a class and you should access them via their properties.
you could declare your window variable without the leading underscore; in this case the #synthetize statement would be simply: #synthetize window, and it would be practically the same.
for the long answer, the links posted by aherlambang are really interesting read...
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