Instance variables declared in ObjC implementation file

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 followi

Answer 1

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.

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

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.