2

I'm still pretty new to ObjC. I noticed that it's pretty standard everywhere to create your

@interface myObj : NSObject {
    id delegate;
    NSDictionary *dict;
}

and then

@property (nonatomic,retain) NSDictionary *dict;
@property (retain) id delegate;

--for example. I know how useful the auto code generation + clearer definition of @property is thanks to the Declared Properties page over at Apple. What I do not understand, however, is why it's standard for people to do both -- declare their properties and then have them again in the {curly brackets}.

I mean, if I had a class where I wanted some of the variables to have auto getters/setters and some not to, then I would understand having the {} block for my regular vars and then only creating @property/@synthesize statements for just those specific variables I wanted to have the added functionality; but why is it standard to always have both in cases where you know that you want all of your instance vars to have the getters and setters? I guess I'm tripping out because I'm basically seeing it used like this 100% of the time when I feel like it really isn't necessary... just declare the @properties and leave it at that.

Thoughts? Best coding practice suggestions? Or is there some information I'm missing here?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Authman Apatira
  • 3,994
  • 1
  • 26
  • 33
  • I exclude IBOutlet from the bracket as a way to organize my thought on what is really owned by the class. But that's just me. – nhahtdh Jun 14 '12 at 13:17

2 Answers2

4

What you're seeing was required in earlier versions of Objective-C, but isn't any more.

In the first versions of Objective-C used by NeXT up until the new runtime was introduced (with Objective-C 2.0 on Mac OS X), all instance variables had to be declared as part of the class's structure in its @interface. The reason was that if you subclassed a class, the compiler needed to know the instance variable layout of the class so it could see at what offset to put the subclass's instance variables.

When properties were introduced, synthesized properties had to be "backed" by an instance variable in the class's structure. Therefore you had to declare both an instance variable and the property.

All of the above is no longer true. Newer Objective-C is less fragile in the way it looks up instance variable offsets, which has meant a few changes:

  • not all instance variables need to be in the @interface. They can now be defined in the @implementation: though not in categories due to the possibilities of clashing and other issues.
  • instance variables for synthesized properties can be inferred and created based on the property definition.
  • you can programmatically add instance variables to classes you're creating at runtime (only before you've registered the class as available to the system).

So, to reiterate, you only needed to declare both the instance variable and a synthesized property in older versions of the Objective-C language. What you're seeing is redundant and should not be considered a "best practice".

0

I tend to think of properties as my public variables as others as private however, you're right when you say "really isn't necessary".

If you omit the ivar, an ivar is still created

I create both so that all of my ivars are together and within the braces just after the interface declaration

@interface MyClass
{
    int variable1;
}
@end
James Webster
  • 31,873
  • 11
  • 70
  • 114
  • Untrue. You can access the instance variable directly even when it's created as a result of a synthesized property and is not otherwise declared in a class. –  Jun 14 '12 at 13:25
  • So you can! Didn't realise that. – James Webster Jun 14 '12 at 13:27