8

So, I've already read up on the documentation which notes

Objective-C 2.0’s dot syntax and key-value coding are orthogonal technologies. You can use key-value coding whether or not you use the dot syntax, and you can use the dot syntax whether or not you use KVC. Both, though, make use of a “dot syntax.” In the case of key-value coding, the syntax is used to delimit elements in a key path. It is important to remember that when you access a property using the dot syntax, you invoke the receiver’s standard accessor methods.

It then provided an example that supposedly showed the difference between the two. However, I still don't get, what's the difference between KVC and property accessor methods? Aren't they the same? And how do I distinguish between dots that call setValue:forKeyPath: and simple accessors?

Vervious
  • 5,559
  • 3
  • 38
  • 57

2 Answers2

15

However, I still don't get, what's the difference between KVC and property accessor methods?

KVC is a way to call property accessor methods, or otherwise access a property.

What do I mean by “otherwise access”? For KVC purposes, an instance variable with no accessor methods counts as an informal property. It'll get or set the value of the instance variable directly if no matching accessor pair can be found. (Yes, this is not worth using in modern code. Always declare an @property for anything you intend to access elsewhere, and, inversely, don't use KVC to access anything that isn't a public property.)

Property accessor methods are what KVC will call if they exist (preferred, both by KVC and by every sane programmer, over direct ivar access). An accessor may get or set an instance variable, as synthesized accessors do, or access some other storage.

Accessors are implementation, properties are interface, and KVC is one way to use them.

And how do I distinguish between dots that call setValue:forKeyPath: and simple accessors?

A key path is a string, whereas a property-access expression is an expression. The compiler evaluates a property-access expression and translates it into one or more Objective-C messages, whereas a key path is evaluated by KVC at run time.

So, when you use a key path:

[someObject setValue:theValue forKeyPath:@"foo.bar.baz"];

You know it's a key path because (1) it's a string, as indicated in this case by the string-literal syntax @"…", and (2) you're passing the key-path string to setValue:forKeyPath: for it to evaluate.

Using a key path is using KVC to access the named properties. It will send any relevant accessor messages on your behalf.

When you use a property-access expression:

someObject.foo.bar.baz = theValue;

You know it's a property access expression because you are not identifying the properties with a string. You are accessing them (sending the accessor messages) yourself, in your own code.

There isn't much reason to use KVC in any form; when you know the property at authorship/compile time, it's best to have an @property declared and to access the property yourself, whether with property-access expressions or message expressions ([[[someObject foo] bar] setBaz:theValue]). The time to use KVC is when you don't know what property you want to access until run time, which is pretty rare. It's mainly a building-block technology behind KVO, Cocoa Bindings, parts of Core Animation, etc.

Mostly, you'll only want to access properties yourself.

Peter Hosey
  • 95,783
  • 15
  • 211
  • 370
  • 4
    **"The time to use KVC is when you don't know what property you want to access until run time"** from your answer is what I was looking for, Thanks. – km3h Aug 29 '13 at 10:11
  • It was really helpful for me. I had in my mind that **The time to use KVC is when you don't know what property you want to access until run time,** this might be the reason but I was not sure. You gave me confident over my thought. – Hemant Sharma Aug 06 '14 at 17:56
  • Peter you state ", and, inversely, don't use KVC to access anything that isn't a public property." I just found out that if a property is declared as read-only and then redeclared as read-write in the implementation, then KVC will shamelessly write to that property. Is there no way to block this? I tried (BOOL) accessInstanceVariablesDirectly { return NO;} but that doesn't prevent KVC from writing to the property. – W S Jun 11 '16 at 13:38
  • @WS: Nope. KVC pre-dates formal properties and has no notion of `readonly` vs `readwrite`, much less publicly-declared-as-X-and-privately-declared-as-Y. It only cares whether there's a getter or a getter and a setter. And if the property is `readwrite`, even if only privately, then that setter exists—and methods in Objective-C have no public/private distinction, so if it exists, it exists for all. – Peter Hosey Jun 11 '16 at 13:57
2

Key value coding allows you to set and get the value of properties through code using the string name of the property. For example, if I had a property named foo which is of type NSString:

[self setValue:@"mystring" forKey:@"foo"];

// read the value by key
NSString *s =  [self valueForKey:@"foo"];

Dot syntax is compile syntax sugar. As a personal preference (as some don't agree - fine) I don't use dot syntax but I still use KVC:

[myObj setFoo: @"someString"]

equals:

myObj.foo = @"someString";

They are orthogonal, different concepts but both dealing with how you interact with properties

Finally, you mention property syntax. Yet another orthogonal concept but related to dealing with properties.

With objective-c, convention is important. Follow them. Properties are the name of the property for the get and set[Name] for the assignment:

- (NSString*)foo
{
    return _foo;  // defined as (NSString*)_foo in header
}

- (void) setFoo: (NSString*)foo
{
    if (foo == _foo)
        return;

    NSString* curr = _foo;

    _foo = [foo retain];
    [curr release];    
}

Now, who wants to write something like that every time. So, enter @property syntax:

In header:

@property (retain) NSString *foo;

Then in .m:

@synthesize foo;

That's the equivalent of the hand written property accessors. It's compiler syntax sugar which expands the property code based on how you attribute the properties.

Docs:

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/KeyValueCoding.html

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html

bryanmac
  • 38,941
  • 11
  • 91
  • 99