11

When declaring the properties in Objective-C, what are the custom options available to configure, which define how the accessor methods would behave?

For example, you can have weak, strong, readonly.

makaed
  • 419
  • 1
  • 5
  • 13
  • 2
    https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html – sosborn Sep 12 '12 at 04:14
  • @sosborn so you can have multiple options within the parentheses, just separated by comma? – makaed Sep 12 '12 at 04:18
  • @makaed yes, but only one that pertains to memory management – Richard J. Ross III Sep 12 '12 at 04:21
  • @RichardJ.RossIII what are the options for memory management? – makaed Sep 12 '12 at 04:24
  • duplicate of [Property and retain, assign, copy, nonatomic](http://stackoverflow.com/questions/2255861/property-and-retain-assign-copy-nonatomic) Also, read the docs. – jscs Sep 12 '12 at 04:45
  • @sosborn The link's broken and I can't find a decent reference for this question to provide a new one. Although @PengOne's answer is great, it fails to mention `getter=...`. I assume there is a `setter=...` as well, although I can't find a resource confirming that... Any others? – Alex Leach Dec 03 '13 at 15:32
  • @AlexLeach [Here](http://web.archive.org/web/20121014210741/https://developer.apple.com/library/mac/#/web/20121014164645/https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html) it is. What is the question about getter/setter? When declaring a property, it will automatically create both getter and setter for you. You can also overwrite them if you need. – makaed Dec 05 '13 at 22:14
  • I was going through the OSX programming tutorial section on [Programming with Objective-C](https://developer.apple.com/library/mac/referencelibrary/GettingStarted/RoadMapOSX/books/WriteObjective-CCode/WriteObjective-CCode/WriteObjective-CCode.html), which specifically mentions overriding the name for the `getter`, but doesn't mention overriding the `setter` name, or quite a few others mentioned by @PengOne below. So I searched for a reference on `@property` attributes and found this Q&A... – Alex Leach Dec 06 '13 at 11:31
  • You can override setter the same way: inside the method you would add your own implementation code in addition to `_instantVariable = argument;`. – makaed Dec 07 '13 at 05:07

1 Answers1

42

Here's the short answer:

atomic vs nonatomic primarily ensures that complete values are returned from synthesized getters and that complete values are written by synthesized setters.

readwrite vs readonly determines whether a synthesized property has a synthesized accessor or not (readwrite has a setter and is the default, readonly does not).

assign vs weak vs retain vs copy determines how the synthesized accessors interact with the Objective-C memory management scheme.

And now for the long answer:

Atomic v Nonatomic

Assuming that you are @synthesizing the method implementations, atomic vs. non-atomic changes the generated code. If you are writing your own setter/getters, atomic/nonatomic/retain/assign/copy are merely advisory.

With atomic, the synthesized setter/getter will ensure that a whole value is always returned from the getter or set by the setter, regardless of setter activity on any other thread. That is, if thread A is in the middle of the getter while thread B calls the setter, an actual viable value -- an autoreleased object, most likely -- will be returned to the caller in A.

In nonatomic, no such guarantees are made. Thus, nonatomic is considerably faster than atomic.

What atomic does not do is make any guarantees about thread safety. If thread A is calling the getter simultaneously with thread B and C calling the setter with different values, thread A may get any one of the three values returned -- the one prior to any setters being called or either of the values passed into the setters in B and C. Likewise, the object may end up with the value from B or C, no way to tell.

Ensuring data integrity -- one of the primary challenges of multi-threaded programming -- is achieved by other means.

Assign, weak, retain, copy

In a nutshell, assign vs weak vs retain vs copy determines how the synthesized accessors interact with the Objective-C memory management scheme:

  • assign is the default and simply performs a variable assignment. It does not assert ownership, so the object pointed to by the property's pointer may disappear at any time if no others have asserted ownership themselves through retain or other means. In an ARC environment, assign does not ensure that pointers will not dangle, which means a pointer may end up pointing to junk if the object on the other side has been deallocated.
  • weak is identical to assign, except that it will zero out pointers that lead to deallocated objects to stop them from dangling. Weak is only available in an ARC environment.
  • retain specifies the new value should be sent -retain on assignment and the old value sent release. Retain is also know as strong.
  • copy specifies the new value should be sent -copy on assignment and the old value sent release. Copy is often used for properties in which the type of the property has a mutable cousin (NSArray/NSMutableArray) to prevent others from sending in mutable versions and altering them/having them altered behind their backs, and more.

Remember that retain/strong is done on the created object (it increases the reference count) whereas copy creates a new object. The difference, then, is whether you want to add another retain to the object or create an entirely new object.

computingfreak
  • 4,939
  • 1
  • 34
  • 51
PengOne
  • 48,188
  • 17
  • 130
  • 149
  • Readwrite vs Readonly doesn't _just_ prevent a getter/setter from being synthesized. It prevents others from accessing the value by handing out errors like candy if they try. Also forgot _weak_, which zeros pointers to prevent them from dangling. I'm guessing you weren't thinking of ARC by your use of _retain_ instead of _strong_. – Metabble Sep 12 '12 at 05:13
  • @Metabble If I understand you correctly, you've voted down my answer not because it's incorrect or unhelpful, but because I do not give a comprehensive answer to a lazy, unspecific question? Moreover, instead of editing my answer or adding an answer of your own to "fill in the gaps", you've left a snarky comment pointing out my oversights. Well, thanks for reminding me why I stopped participating in this site. I hope you're here to help when I forget again in another six months. – PengOne Sep 12 '12 at 15:53
  • I am sorry if you took my comment as snarky, as I did not intend it in to seem that way, and thought your answer was very helpful. I didn't edit your answer because I was in the middle of answering someone else, if I recall correctly, and was brought back into a conversation immediately after typing that out. Also, I don't know who voted down your answer, but I am almost sure it was not me. I do not take downvotes lightly, and would never downvote a near-perfect, useful answer! :) – Metabble Sep 12 '12 at 16:43
  • Also, just to add, I didn't edit because I wasn't quite sure if I was right about the compiler error thing. Although Apple says it does cause an error in its own documentation, it's only because it never synthesized a setter. In fact, if you make your own and make it public you can still use dot notation and set it as if the property were readwrite with no errors. I will edit to add a small part about weak. – Metabble Sep 12 '12 at 16:52