Private ivar in @interface or @implementation

Question

Is there any reason to declare a private ivar in @interface instead of @implementation?

I see code like this all over the internet (including documentation provided by Apple):

Foo.h

@interface Foo : NSObject {
@private
    id _foo;
}
@end

Foo.m

@implementation Foo
// do something with _foo
@end

The header file defines the public interface of a class, whereas a private ivar is... well... private. So why not declare it like this?

Foo.h

@interface Foo : NSObject
@end

Foo.m

@implementation Foo {
@private
    id _foo;
}

// do something with _foo
@end

Answer 1

Declaring instance variables in the @implementation is a recent feature of Obj-C, this is why you see a lot of code with them in the @interface - there was no other choice.

If you are using a compiler which supports declaring instance variables in the implementation declaring them there is probably the best default - only put them in the interface if they need to be accessed by others.

Edit: Additional Info

Instance variables declared in the implementation are implicitly hidden (effectively private) and the visibility cannot be changed - @public, @protected and @private do not produce compiler errors (with the current Clang at least) but are ignored.

Answer 2

The directives @public, @protected, and @private are not binding in objective-C, they are compiler hints about the accessibility of the variables. It DOES NOT RESTRICT YOU from accessing them.

example:

@interface Example : Object
{
@public
int x;
@private
int y;
}
...


...
id ex = [[Example alloc ] init];
ex->x = 10;
ex->y = -10;
printf(" x = %d , y = %d \n", ex->x , ex->y );
...

The gcc compiler spits out :

Main.m:56:1: warning: instance variable ‘y’ is @private; this will be a hard error in the future

Main.m:57:1: warning: instance variable ‘y’ is @private; this will be a hard error in the future

once for each "innapropriate" access to "private" member y, but compiles it anyway.

When run you get

x = 10 , y = -10

So it really is up to you NOT to write access code this way, but because objc is a superset of C, C syntax works just fine, and all classes are transparent.

You can set the compiler to treat these warnings as errors and bail -- but objective-C is not set up internally for this kind of strictness. The dynamic method dispatch would have to check for scope and permission for each call ( slooooowwwww... ) , so beyond a compile-time warning, the system expects the programmer to respect data member scoping.

There are several tricks to getting privacy of members in objective-C. One is to make sure you put the interface and implementations of your class in separate .h and .m files, respectively, and put the data members in the implementation file (the .m file). Then the files that import the headers do not have access to the data members, only the class itself. Then provide access methods (or not) in the header. You can implement setter/getter functions in the implementation file for diagnostic purposes if you want and they will be callable, but direct access to the data members will not be.

example:

@implementation Example2 :Object
{ 
 //nothing here
}
double hidden_d; // hey now this isn't seen by other files.
id classdata;    // neither is this.

-(id) classdata { return [classdata data]; } // public accessor
-(void) method2 { ... }
@end

// this is an "informal category" with no @interface section
// these methods are not "published" in the header but are valid for the class

@implementation Example2 (private)
-(void)set_hidden_d:(double)d { hidden_d = d; }

// You can only return by reference, not value, and the runtime sees (id) outside this file.
// You must cast to (double*) and de-reference it to use it outside of this file. 
-(id) hidden_d_ptr { return &hidden_d;}
@end

...
[Main.m]
...
ex2 = [[Example2 alloc] init];

double d = ex2->hidden_d; // error: 'struct Example2’ has no member named ‘hidden_d’
id data = ex2->classdata; // error: 'struct Example2’ has no member named ‘classdata’
id data = [ex2 classdata] // OK

[ex2 set_hidden_d : 6.28318 ]; // warning:'Example2' may not respond to '-set_hidden_d:'

double* dp = [ex2 hidden_d_ptr]; // (SO UGLY)  warning: initialization from incompatible pointer type
                                 // use (double*)cast -- <pointer-to-pointer conversion>  
double d = (*dp); // dereference pointer (also UGLY). 

...

The compiler will issue warnings for such blatant shenanigans, but will go ahead and trust that you know what you are doing (really?), and that you have your reasons (do you?). Seem like a lot of work? Error Prone? Yay Baby! Try refactoring your code first before resorting to magic C tricks and meatball surgery like this.

But there it is. Good luck.

Answer 3

You would favor @interface if you need compiler support targeting older systems or releases of Xcode.

If you are certain you will not need that backwards compatibility, I'd say it's best to place it in the @implementation.

• I think @private is a good default.
• It minimizes compile times, and reduces dependencies if you use it right.
• You can reduce much of that noise at the top of your header. Many people will put #imports for their ivars, but they should use a forward declaration as default. So you can remove many #imports and many forward declarations from your header.