You want to use copy
for value-semantic-typed properties. (Of which NSString
is always one.) Otherwise, I can pass you an instance of NSMutableString
and then change it out from under you after the fact. Immutable objects will implement -copyWithZone:
by doing return [self retain]
; so as to not actually create a second copy when it's not needed. See also: NSString property: copy or retain?
In terms of your -init
method, you want to avoid using the property setters like you have since they could be overridden in a subclass to do something unforeseeable by your class. So assuming default auto-ivar-synthesis naming pattern, you would want to do this:
-(id)initWithName:(NSString *)n andCity:(NSString *)c
{
if (self = [super init])
{
_name = [n copy];
_city = [c copy];
}
return self;
}
It's a subtle thing, and it won't often be a problem, but if you continue to use inherently-virtual property setters in -init
and -dealloc
methods, over a long enough timeline, you will get burned by this (can you tell I've been burned by this?)
As for leaked memory, if you're using ARC, doing something like self.foo = [bar copy];
when foo is a copy
property will result in copy getting called twice, and potentially two copies being made, but ARC should take care of properly releasing the redundant/intermediate copy, and there should not be a memory leak.