【问题标题】:No ivars -> What am I missing?没有 ivars -> 我错过了什么?
【发布时间】:2011-09-14 15:22:24
【问题描述】:

我从不使用 ivars。我只使用属性——有时使用原始类型分配属性,有时使用"private" class extension。我已经看到了在切换到 ARC 时不使用 ivars 的优势——我有一些借用的代码,其中包含很多我仍然不能“ARC”的 ivars,因为我不知道需要保留什么。所以我知道使用 ivars 的一些优点,但是使用 ivars 代替属性有什么优点呢?

注意:我完全依赖于(由编译器?)自动添加的 ivars 来进行属性声明。

不要标记为关闭:我已经查看了其他一些问题,例如 thisthis ,但没有一个是正确的。 标题看起来不错,但就像关于 SO 的许多问题一样,这些问题是一堆奇怪的疑问和其他东西。

【问题讨论】:

  • 参见stackoverflow.com/questions/6112283/question-about-synthesize/…“访问器综合的行为取决于运行时...”使用@property 并手动声明ivars 仅对支持遗留运行时有用(afaik) .
  • 哎呀,很抱歉读了这么久。我只想向您指出来自Property Implementation Directives 的引用,它指出合成发生在编译时。我无法找出 ivars 的案例,而不是现代运行时中的属性。这是一个有趣的问题,我会进一步研究它。
  • 想一想:所有作用域编译器指令(@private 等)的效果都可以通过属性来实现吗?我知道readonlyreadwrite,但是这些(可能在类扩展的帮助下)能否涵盖所有必需的范围?
  • @StuDev, @private 很容易模仿,但@protected 已经更难了(如何强制子类使用类扩展,而其他类忽略它?)。所以我认为你正在开始一个非常有趣的答案。不幸的是,这个问题没有被 63,000 只大猩猩在没有任何谷歌搜索或研究的情况下回答这个问题,所以它在我们身上。
  • @Yar,经过一番研究,我想我会发布这个作为答案......似乎没有办法声明一个被视为受保护的属性。跨度>

标签: objective-c ios automatic-properties


【解决方案1】:

声明的属性不能以与@protected ivar 相同的方式处理。您可以在类扩展中声明该属性以使其对任何其他类保持私有,或在头接口中声明以使其可公开访问,但是无法使其仅对子类可访问。这需要 ivar 声明。

编辑

只是另一个简短的想法。最近一直在写很多框架类,我觉得使用iVars作为文档可能有话要说。

例如,假设您正在一个紧密循环中调用一些代码,并且您希望确保它是高性能的。在该紧密循环中,您想要访问类的属性,但需要知道每次调用它时返回值是即时计算还是存储在 iVar 中。查看标头中的 iVar 是一种快速的方法,可确保您无需太多开销即可取回该变量。

【讨论】:

  • 注意:除非我读错了——stackoverflow.com/questions/1933438/…——甚至@protected@private 都可以通过类别公开。您的观点仍然有效且有趣,但看起来令人困惑的 iVar 的死亡还不会很快到来。
  • @Yar:是的,听起来确实不是。 Objective-C 似乎以“提供足够的绳子来吊死自己”而闻名,但是有许多容易通过的低栅栏来警告你不要太靠近绞刑架(抱歉这个可怕的比喻)。我实际上很喜欢这个想法,但是当你开始意外覆盖不应该被覆盖的东西时问题就来了。虽然,我确实认为 Mac 和 iOS 开发人员可能被“培养”来进行防御性编码并遵循惯例,以至于在大多数情况下这些陷阱并不是什么大问题。
  • 伟大的评论,隐喻。经验事实是,尽管到处都是滑稽的地雷,但在 Obj-C 中构建了出色的应用程序。事实上,它似乎可能会淘汰一些白痴。就个人而言,我想出了更多的防白痴语言,例如 Java(我将忽略窃笑),但也许从全球角度来看,让您的工作更轻松的防白痴语言可能更糟糕。
  • @yar 你说得对,双刃剑/高门槛。 objc 真的看起来和感觉一团糟——即使是最聪明的人——一开始,第二次,一直如此——很多次。直到没有。我真的怀疑大多数白痴是否有耐心坚持一些看起来如此奇怪和愚蠢的事情......起初......
【解决方案2】:

如果您不必使用 iVar,我认为没有任何理由。如果 Apple 和编译器想为你工作,我说让他们做。您将拥有更高效且更易于维护的代码。在这一点上,iVar 是遗留代码。

【讨论】:

  • 感谢@SSTeve,这就是我的想法(是不是很明显),但我期待对此有一些反对者。
  • 我想知道这是否是为什么当你创建一个新的子类时,Apple 的 @interface 声明样板代码不再包含 iVar 声明的花括号......?我必须承认我自己一直都包含 iVars,但是看完这个问题我什至不知道为什么!
  • @StuDev,不要感到难过:从长远来看,遵循规则/约定(即使它们毫无意义)的开发人员往往会遇到更少的问题。但是,是的,这就是 IMO 为什么 Apple 去掉了花括号,但这并不是你可以问 Apple。我敢肯定,在 WWDC 的某个时刻,一些随机开发者可能会提到它。
  • 我确信模板的发展是为了鼓励使用@properties,它比ivars 提供了一些好处。我知道 Yar 只是在寻找极端案例。非正式地在 cocoa-dev 有一些 Apple 开发人员,但没有人分配给它。
【解决方案3】:

我有一个很好的理由:一个烦人的 GCC 错误,请参阅 this other question 了解说明。

如果您使用的是 Clang/LVVM,那么您不必担心这个错误。

【讨论】:

  • 1) 不,我在 iOS 上遇到过这个错误。 2) 调试器是 GDB,它与 GCC 没有(真正)相关。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-06-10
  • 1970-01-01
  • 2013-08-12
  • 1970-01-01
相关资源
最近更新 更多