CODEWITHSUNDEEP
iosobjective-cmemory-management
chengxcv5
chengxcv5

Reputation: 177

how can I look up objective-c's property @synthesize getter setter code

in interview has a question "Could NSMutableArray property use copy why and why not " I have searched the answer but I want to see the auto generate's getter setter code how can I do?

Upvotes: 1

Views: 185

Answers (2)

CRD
CRD

Reputation: 53010

You cannot see the Obj-C code for the setter only the assembler. To do this first select the source file containing the property in Xcode and then choose the menu item Produce > Perform Action > Assemble "File.m". This will open up a window containing the assembly code. Search for setPropertyName: where PropertyName is the capitalised name of your property.

This will show you the setter calls _objc_setProperty_nonatomic_copy or _objc_setProperty_atomic_copy. To see the code for those you will need to use the debugger and step into them. They essentially just call copyWithZone:.

More important is the reason behind the interview question. Either simple experimentation, or digging through the assembler as above, shows that the copy property attribute always does a copy and not a mutableCopy. So the declaration:

@property (nonatomic, copy) NSMutableArray *shouldBeInvalid;

would in an ideal world generate a compiler error. If you assign a mutable array value to the property:

self.shouldBeInvalid = @[ @24 ].mutableCopy;

then due to the copy the value actually assigned is an immutable array (NSArray), contradicting the NSMutableArray declared type. Trying to use the property value later as a mutable array:

[self.shouldBeInvalid addObject:@42];

will produce a runtime error as the property's value is an immutable object contrary to its declared type...

You'll also find that the compiler happily allows you to assign an immutable array to the property:

self.shouldBeInvalid = @[ @24 ];

without so much as a warning.

What the interviewer was probably seeking was for you to explain that for a property copy + mutable type makes no sense in Objective-C as the copy will produce an immutable object value. However a property with copy and an immutable object type (NSArray, NSDictionary, etc.) does make sense so that if a mutable object value is assigned an immutable copy of it is made, which prevents the property's value changing unexpectedly, e.g.:

@property (nonatomic) NSArray *shouldHaveCopy;

NSMutableArray *sample = @[ @"oops" ].mutableCopy;

self.shouldHaveCopy = sample;

[sample addObject:@"'immutable' property changed"];

// self.shouldHaveCopy now references a two element array despite
// its type being `NSArray`

So the general rules are:

  • A property intended to have a mutable object value (NSMutableDictionary et al) should never specify copy; and
  • A property intended to have an immutable object value, when there is a corresponding mutable object subclass (e.g. NSArray has NSMutableArray etc.), should always specify copy.

HTH

Upvotes: 3

uliwitness
uliwitness

Reputation: 8843

You can‘t really see the source code. You could step into it in Xcode‘s debugger though, and see an assembler version of it, which is reasonably readable if you know any platform‘s assembler or are good at guessing abbreviations for english words.

Upvotes: 0

Related Questions