8

I never use ivars. I only use properties -- sometimes assign properties with primitive types, and sometimes on a "private" class extension. I've seen the advantages of not using ivars in switching to ARC -- I have some borrowed code with lots of ivars that I still can't "ARC", since I don't know what needs to be retained. So I know some advantages of not using ivars, but what are the advantages of using ivars instead of properties?

Note: I depend exclusively on the ivars that are automagically added in (by the compiler?) for the property declaration.

Don't mark to close: I've looked at some of the other questions, like this and this and none hit the spot. The titles look good, but like so many questions on SO, the questions are a mess of strange doubts and other stuff.

Community
  • 1
  • 1
Dan Rosenstark
  • 68,471
  • 58
  • 283
  • 421
  • 1
    See http://stackoverflow.com/questions/6112283/question-about-synthesize/6112553#6112553 "There are differences in the behavior of accessor synthesis that depend on the runtime..." Using @property and manually declaring the ivars is only useful to support the legacy runtime (afaik). – Jano Sep 14 '11 at 16:58
  • @Jano, is that very long-winded answer relevant? If so, how? It's understood that properties use accessors, and that's there's a difference between `self.thing = that` and `thing = that`. So? – Dan Rosenstark Sep 14 '11 at 18:22
  • 2
    Ouch, I'm very sorry for the long read. I only wanted to point you to the quote from [Property Implementation Directives](http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW9) which states that synthesize happens at compile time. I can't figure out a case for ivars instead properties in the modern runtime. It's an interesting question though, I'll look more into it. – Jano Sep 14 '11 at 22:21
  • 1
    Just a thought: can the effect of all of the scope compiler directives (`@private` etc) be achieved with properties? I am aware of `readonly` and `readwrite`, but can these (perhaps with the help of class extensions) cover all required scopes? – Stuart Sep 15 '11 at 08:16
  • 1
    @StuDev, `@private` is easy enough to imitate, but `@protected` is already harder (how do you force subclasses to use the class extension, and other classes to ignore it?). So I think you're on to the beginning of a very interesting answer. Unfortunately, this question was no picked up by the 63K gorillas who could answer it without any googling nor research, so it's on us. – Dan Rosenstark Sep 15 '11 at 12:38
  • 1
    @Yar, after a little bit of research, I think I'm going to post that as an answer... seems there is no way to declare a property that is treated as protected. – Stuart Sep 15 '11 at 12:51

3 Answers3

4

Declared properties cannot be treated in the same manner as an @protected ivar. You can declare the property in a class extension to keep it private from any other class, or declare it in the header interface to make it publicly accessible, however there is no way to make it accessible only to subclasses. This would require the ivar declaration.

EDIT

Just another brief thought. I have recently been writing a lot of framework classes, and I think there might be something to be said for using iVars as documentation.

For example, let's say you are calling some code in a tight loop and you want to ensure that it is performant. Inside that tight loop you want to access a property of a class, but need to know whether each time you call it the return value is calculated on-the-fly or stored in an iVar. Seeing the iVar in the header is a quick way to ensure that you'll get that variable back without much overhead.

Stuart
  • 36,683
  • 19
  • 101
  • 139
  • 2
    Note: Unless I'm reading this wrong -- http://stackoverflow.com/questions/1933438/marking-instance-variables-private/1933537#1933537 -- even `@protected` or `@private` can be made public via categories. Your point is still valid and interesting, but it looks like the death of confusing iVars could not come soon enough. – Dan Rosenstark Sep 15 '11 at 17:21
  • @Yar: Yes it does sound like it doesn't it. Objective-C seems to be famous for "providing just enough rope to hang yourself with", but with lots of easily negotiated low fences to warn you from getting too close to the gallows (sorry for the terrible metaphor). I actually quite like that as an idea, but the problems come when you start _accidentally_ overriding things that shouldn't be overridden. Although, I do think that Mac and iOS developers are probably 'brought up' to code defensively & follow conventions to the point that these pitfalls aren't a big problem in most cases. – Stuart Sep 16 '11 at 15:43
  • 1
    great comment, metaphor aside. The empirical facts are that great apps are built in Obj-C despite the zany land mines laying everywhere. In fact, it seems to perhaps weed out some of the morons. Personally, I came up with more idiot-proof languages like Java (I'll ignore the snickering), but perhaps in a global view, idiot-proof languages that make your job easier are perhaps worse. – Dan Rosenstark Sep 16 '11 at 19:26
  • 1
    @yar You're so right about the double-edged / high barrier to entry. `objc` genuinely looks and feels a MESS - to even the smartest person - at first, second, and on and on - for MANY glances. Until it doesn't. I really doubt most idiots would ever hasve the patience to stick with something that seems so bizarre and stupid... At first.... – Alex Gray Apr 05 '12 at 08:28
3

I don't see any reason to use iVars if you don't have to. If Apple and the compiler want to do work for you, I say let them. You'll have code that more efficient and easier to maintain. At this point iVars are legacy code.

SSteve
  • 10,550
  • 5
  • 46
  • 72
  • Thanks @SSTeve, that's what I think (was it that obvious), but I'm looking forward to some dissenters on this one. – Dan Rosenstark Sep 14 '11 at 16:13
  • I wonder if this is why when you create a new subclass, Apple's boilerplate code for the `@interface` declaration no longer includes the curly braces for iVar declarations...? I must admit I have always included iVars myself, but after reading this question I don't even know why! – Stuart Sep 14 '11 at 16:51
  • @StuDev, don't feel bad: developers who follow the rules/conventions (even when they make no sense) tend to get into fewer problems, in the long run. But yeah, that's IMO why Apple got rid of the curly braces, but it's not like you can just ask Apple. Somewhere at some point in the WWDC some random dev probably mentions it, I'm sure. – Dan Rosenstark Sep 14 '11 at 18:24
  • 2
    I'm sure templates evolved to encourage the use of @properties, which offer several benefits over ivars. I understand Yar is just looking for corner cases. Unofficially there are some Apple devs at cocoa-dev, but no one assigned to it. – Jano Sep 14 '11 at 22:57
1

One good reason for me: an annoying GCC bug, see this other question for a description.

If you're using Clang/LVVM, then you don't have to worry about this bug.

Community
  • 1
  • 1
jv42
  • 8,521
  • 5
  • 40
  • 64
  • 1
    1) No I experienced that bug on iOS. 2) The debugger is GDB, which is not (really) related to GCC. – jv42 Sep 15 '11 at 18:31