在ObjC实现文件中声明的实例variables
我正在观看WWDC ARC介绍video，在苹果的一位工程师谈到Stack示例时，我看到了在ObjC中从未见过的东西。
以下代码用于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 请注意在@implementation指令后面声明的实例variables。
现在让我感到吃惊的是，一个实例variables实际上可以在实现文件中声明，而不是一个静态variables。 我的问题如下：
- 这是在iOS 5的SDK中引入了一些新的构造还是可以很长一段时间吗？
- 在实现中声明实例variables是否是一种好的做法，如果实例variables不在对象之外访问？ 看起来似乎更清洁，然后使用@private指令。
这确实是一种新的语言function，如果您必须声明您的ivars（而不是简单地声明属性并让编译器为您生成ivars），这是一个好习惯。 理论上你的头文件应该只为你的类暴露公共接口; 一切都属于实施。
一个需要注意的是，实现文件ivars对于子类是不可见的，如果你有手动生成的setter和getters需要子类，偶尔会有点尴尬。
在实现中声明iVars肯定是目标C中的一个新构造。您需要使用xcode4.2并在构build设置中selectLLVM编译器。 这个想法是保持你的头文件更清洁。 你可以像这个例子一样在大括号里面列出你的ivars;
@implementation MyClass { int var1; int var2; }
Rahul给出的答案并不是真的正确，尽pipe你可以按照他所说的方式来拖延variables，编译器会认为这些variables是静态的。 可能对于他使用它们的情况来说，这并不重要。
我是Objective C的新手，我发现在头文件中声明ivars的做法非常奇怪。 它意味着在公开头文件中声明一个对象的内部状态，这违背了封装的概念。
例如说你拥有一个iPad。 苹果不希望你打破iPad的开放和撬动，并与内部元素混乱。 如果他们希望你修改某些东西，iPad将会有一个设置让你改变它。
同样，我不希望其他程序员看到我的对象的ivars。 它是我的对象的内部状态。 如果我想让你访问内部状态，我会为它声明属性。
所以，和其他语言一样，我会将我的ivars隐藏在实现文件中，而不是在头文件中声明它们。
在头文件中声明ivars只是让我非常奇怪。 这些ivars是特定于实现的，并且不应该成为头文件的一部分。
