This question already has answers here:
How do I declare class-level properties in Objective-C?
(10 answers)
Closed 8 years ago.
To declare an instance property you can use a declaration similar to this:
#property (readonly) int size;
The property can later be accessed using the dot syntax:
NSLog(#"The object has a size of: %d", objectInstance.size);
However, I'd like to declare a class property so that, even without an instance, I can access it in this manner. For example:
NSLog(#"%d instances have been created.", ClassName.numberOfInstances);
I know I could always implement this behaviour using a class message and call it using the dot syntax anyway, but I'd prefer having a declared property and would benefit from the #synthesize directive for some of the properties.
Is this possible?
The short answer is that no, you can't. The compiler will not let you do it. You can see that when Apple has to do something similiar (like for the UIView implicit animation parameters) they use KVC compliant naming put do not declare them as properties.
The longer answer is that classes are objects and I can in fact envision some pretty grotesque hacks that involve proxy redirections that let you do it, but it is really not something I would recommend doing.
Related
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
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:
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