Why is it needed to declare ivar and property with the same name?

Question

In most project before Xcode 4.4, I realized that developers declared simultaneous an ivar and a property with the same name. Example

@interface SecondViewController : UIViewController
{
     NSString *string;
}

@property (strong, retain) NSString *string;

So I don't know why ?

Auriscope

dup: #5556236 – Scoff

Answer 1

Just a matter of style and used to behavior from past compilers.

Now in newer compiler this is not required. As soon as you create a property an ivar is created behind the scene as well as it gets synthesized.

Compiler synthesizes with an alias as _propertyName, even you can opt to change this default behavior.

@interface AppDelegate : NSObject <NSApplicationDelegate>{
    NSString *bigString;
}
@property(strong)NSString *smallString;
@end

---

@implementation AppDelegate
@synthesize smallString=bigString;
-(void)awakeFromNib{
    self.smallString=@"hello";
    NSLog(@"%@",self.smallString);
}

@end

Carn

This is the correct answer, +1. It's not a matter of Xcode version, it's a matter of language dialect version, which is implemented in a certain version of the compiler. – Biblical

@H2CO3: Thanks, And whenever you give +1 to me, I feel GOOD :) – Carn

What meaning of this line @synthesize smallString=bigString; – Auriscope

I made smallString to work for bigString. Now you cant access bigString in the class. I just showed this to make it clear how can be link an iVar to a property, even then they are of different names – Carn

Answer 2

I can't speak for others, but I don't use the same name. If I do declare an instance variable , it's with a leading underscore, so it's obvious if I'm referring to the instance variable or the setter/getter method.

With Xcode 4.4+ you don't need to declare the instance variable or call @synthesize and the compiler will automatically create an instance variable, with a leading underscore, and provide the setter/getter method for you.

However I don't think this mechanism is a very good idea, as it encourages developers to expose properties of the their class that should not be exposed.

For example, this is taken from Beginning iOS 6 Development:

@interface BIDViewController : UIViewController
@property (weak, nonatomic) IBOutlet UIButton *button;
- (IBAction)buttonPressed:(UIButton *)sender;
@end

Now, while I understand that you don't want to confuse a beginner with too many concepts at once, you have immediately violated Object Oriented Encapsulation by exposing both the UIButton object and the action method to users of this view controller, and neither should be exposed.

What happens, for example, if a using class does this:

BIDViewController *vc = ...;
vc.button = nil;

or

vc.buttonPressed(mySegmentedControl);

All hell breaks loose. Now while there are a 1000 ways to break a program and we cannot defend against all of them, we don't want to make an already weak system (Objective-C provides precious little in terms of defining who can and can't call one of your methods) weaker.

The above implementation is better done using private instance variables and methods, both of which are honoured by Interface Builder:

@implementation BIDViewController ()
{
    IBOutlet UIButton *_button;
}
- (IBAction)_buttonPressed:(UIButton *)sender;

@end

and any using classes will have a tougher time of breaking that model.

But of course this is more thinking and typing for a developer, and so Apple have introduced the new features so they can get what they want done in less time (there is very little typing when you simply drag an outlet to a header file and both the declaration and implementation skeleton is provided for you).

Sofa

"so it's obvious if I'm referring to the instance variable or the setter/getter method" - it's obvious anyway: self.foo is a property, foo is an ivar. – Biblical

As you can see in this post: inessential.com/2010/06/28/how_i_manage_memory The author use an ivar and a property with the same name. And I don't understand his intention. – Auriscope

@DungProton I've no idea what you are referring to. – Sofa

I prefer to just declare "private" (I know they are not really) ivars/properties in a class extension. That way I still get accessors generated and I don't have to think is this public/private I can call use the properties and ivars in the same way as if it was publicly visible or not. – Campus