views:

81

answers:

3
NSString *statusValue;
NSString *currentValue;

@property(retain, nonatomic) NSString *statusValue;
@property(retain, nonatomic) NSString *currentValue;

@synthesize statusValue;
@sythnesize currentValue;

Given the above, if I am setting one variable to another should I be doing ...

[self setStatusValue: currentValue];

or should I use the property again and use ...

[self setStatusValue: [self currentValue]];

I suppose the latter (although maybe overkill) does tell the reader that we are using one of the objects instance variables and not some local variable.

just curious really, I was going with the bottom one, but just wanted to check before someone looked at my code and when "what the hell" :)

gary

A: 

This works and is more expressive IMO:

self.statusValue = currentValue;

ifwdev
in the 'c' world, yes; in the obj-c world, no.
KevinDTimm
As of Objective-C 2.0 `self.statusValue = currentValue;` is syntactic sugar for `[self setStatusValue:currentValue];`, also known as "dot syntax".
Perspx
+3  A: 

Both work just fine. Which one you use may depend on the side-effects you wish. For example, by using [self currentValue], you may fire off willAccessValueForKey: and didAccessValueForKey: KVO notifications, but only if somebody's actually observing that property, and only if it's an NSManagedObject subclass. Usually there aren't any major side effects.

Personally, I'd probably use the latter example, just so that I don't have to worry about changing the name of an iVar in 30 places if I decide to change it (of course, the Refactor->Rename tool would be the right to use in that situation, but still).

Dave DeLong
+2  A: 

I use the latter in the absence of a compelling reason not to. That way it works with overridden accessors, changed implementations, etc. without any changes. For example, maybe I decide to switch from storing the statusValue as a string and instead store a Status object with statusValue going through that. If I'm manually accessing the ivar all over the place, I have to change all of them. If instead I'm going through the class's public interface, I only have to change the one accessor method.

Chuck