Proposal: specify that all immutable object properties should be marked "copy"

[jspahrsummers]

From discussion on libgit2/objective-git#103.

Rendered Markdown

[joshaber]

👍

[dannygreg]

Just to present my alternate use: I feel copy should be used when a different object is returned each time. Seems to be way more in the line of a "copy".

That said I am not 👎 on @jspahrsummers' suggestion… I just prefer that ^.

[jspahrsummers]

I've never understood assign, strong, weak, or copy to apply to how the object in question is returned. To me, they only make guarantees about how the implementation is going to manage set values.

[dannygreg]

Woops thought I had replied. You've convinced me. I'm 👍. In @alanjrogers's absence Imma just merge this as his opinion no longer matters

[felixvisee]

What's your opinion or best practice on this with a mutable subclass, @jspahrsummers and @dannygreg? For example:

@interface Foo : NSObject { @protected NSArray *_bar; } @property (readonly, nonatomic, copy) NSArray *bar; @end @implementation Foo - (instancetype)init { self = [super init]; if (self) _bar = @[ @"hello world" ]; return self; } @end @interface MutableFoo : Foo @property (readwrite, nonatomic, copy) NSArray *bar; @end @implementation MutableFoo - (void)setBar:(NSArray *)bar { _bar = [bar copy]; } @end

Foo will neither change the elements of the array returned by -bar nor _bar (after init). However, MutableFoo will change _bar, but never the elements of any array returned by -bar. copy or strong?

[jspahrsummers]

Unless the array's contents need to be mutated, any array property should be copy, since it just performs a shallow copy. It ensures that your property never becomes a mutable array, and your elements remain individually mutable (if they originally were).

[felixvisee]

Ok, got it. I was a little bit confused by the and. Thanks :)