Instance variables declared in ObjC implementation

Question

I was watching the WWDC ARC introduction video and I saw something I've never seen in ObjC before when some Apple engineer talked about a Stack example.

The following code was used for a stack example with ARC:

@implementation Stack 
{ 
    // instance variable declared in implementation context
    NSMutableArray *_array; 
}

- (id)init 
{
   if (self = [super init])
      _array = [NSMutableArray array];
   return self;
}

- (void)push:(id)x 
{
   [_array addObject:x];
}

- (id)pop 
{
   id x = [_array lastObject];
   [_array removeLastObject];
   return x;
}

@end

Please note the instance variable declared right after the @implementation directive.

Now the thing that surprised me, is that an instance variable could actually be declared in the implementation file, without it being a static variable. My questions would be the following:

• Is this some new construct introduced in the SDK for iOS 5 or has this been possible for a long time?
• Would it be good practice to declare instance variables in the implementation, if the instance variables are not to be accessed outside the object? It seems way cleaner then the use of the @private directive.

Answer 1

Declaring iVars inside the implementation is definately a new construct in objective C. You need to be using xcode4.2 and have the LLVM compiler selected in your build settings. The idea is to keep your header files cleaner. You can list your ivars inside curly braces like this example;

@implementation MyClass {    
  int var1;
  int var2;
}

The answer given by Rahul is not really correct, although you can delare variables in the way he says they would be looked upon as static by the compiler. Probably for the cases in which he used them it didnt matter.

Answer 2

This is indeed a new language feature, and if you must declare your ivars (rather than simply declaring properties and letting the compiler generate ivars for you) it's a good practice. Your header files in theory should only expose public interface for your classes; everything else belongs in the implementation.

One caveat is that implementation-file ivars are not visible to subclasses, which can occasionally be a little bit awkward if you have manually generated setters and getters that you need to subclass.

Answer 3

I am new to Objective C, and I found the practice of declaring ivars in the header very very odd. It means declaring the internal state of an object in its public header, which defies the concept of encapsulation.

For example say you own an IPad. Apple does not want you to break the IPad open and pry around , and mess with the elements inside. If they want you to modify something, the IPad will have a setting that let you change that.

Similarly I dont want other programmers to see the ivars of my objects. Its the internal state of my object. If I want you to acess the internal state, I will declare properties for it.

So, as in other languaes, I would hide my ivars inside the implementationfile, and not declare them in the header.

Declaring ivars in the header just strikes me as very very odd. Those ivars are implementation specific, and should simply not be part of the header file.