mikeash.com pyblog/friday-qa-2013-02-08-lets-build-key-value-coding.html comments

Ivan - 2015-09-30 23:09:59

Wed, 30 Sep 2015 23:09:59 GMT

Hi Mike, thank you for your great articles, carry on writing please!

I've found a mistake in the article. Actually, the property searching algorithm looking at underscored ivars before then non-underscored ones. Moreover, it checks ivars started with is, thus the complete search path is: setter/getter -> _<Key> -> _is<Key> -> <Key> -> is<Key>.

Actually there is many of other interesting things about searching algorithms in KVC, all of them are describet here http://apple.co/1KSAh1t

Recovery - 2014-10-20 14:01:03

Mon, 20 Oct 2014 14:01:03 GMT

What's the best way to pass values to different video controllers, KVC, Delegate or something else?

Morty Eraser - 2014-10-16 15:33:55

Thu, 16 Oct 2014 15:33:55 GMT

This is indeed an amazing tutorial on explaining one of the most important concepts in iOS programming. Looking forward to more posts like this one in future.

Carick - 2014-10-13 16:34:10

Mon, 13 Oct 2014 16:34:10 GMT

I found KVC is great for passing values between UIViewControllers, especially for segues. It's much simple than Delegate, which i am still confused although learnt the concept a few months ago.

BTW, really great tutorial. I need to spend some time to fully digest the content.

Manoj - 2013-03-25 10:04:29

Mon, 25 Mar 2013 10:04:29 GMT

Great article !!

Always impressed the way you put down things in simple but in precise.

George - 2013-02-16 15:31:24

Sat, 16 Feb 2013 15:31:24 GMT

Mike, i'm wondering... did you work at Apple, or actually have a friend inside?. I'm amazed by the simplicity of your implementations... and i was just being curious about... if you wrote the actual thing!

Matthias Plappert - 2013-02-13 06:55:16

Wed, 13 Feb 2013 06:55:16 GMT

Great article. One thing that seems to be missing are @properties with a custom getter, e.g.

@propert (assign, getter=isEnabled) BOOL enabled;

Any insight how does work with KVC?

Justin Spahr-Summers - 2013-02-10 07:38:28

Sun, 10 Feb 2013 07:38:28 GMT

Great article!

It's worth noting that KVC will only access ivars if +accessInstanceVariablesDirectly isn't overridden to return NO: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/Reference/Reference.html#//apple_ref/occ/clm/NSObject/accessInstanceVariablesDirectly

The behavior of nil when using KVC to set a primitive value is also somewhat interesting.

Gwendal Roué - 2013-02-09 01:43:44

Sat, 09 Feb 2013 01:43:44 GMT

Some experience around KVC:

GRMustache (https://github.com/groue/GRMustache) is a template engine based to valueForKey:

1. The Mustache (http://mustache.github.com/mustache.5.html) language has a "context stack" where a simple tag such as {{ name }} can send the valueForKey: message to many objects, until one returns a non-nil value, that gets rendered.

Unfortunately, developers don't like NSUndefinedKeyException to stop their debugger when valueForKey: raises an exception. Those exceptions are properly caught and processed, yet developers were thinking some problem did happen. This was an annoyance I had to fix. I had to avoid as much of valueForKey: exceptions as I could.

Swizzling NSObject and NSManagedOject implementations of valueForUndefinedKey:, so that those methods return nil if the receiver is in the set of "quiet" objects for the current thread, was a good enough solution. Mike Ash, I don't know if you remember, but you sent me on the right track on this topic. Thank you for that.

2. NSArray, NSSet and NSOrderedSet have a funny implementation of valueForKey: they return another collection built from the invocation of valueForKey: on their elements. This behavior led to several problems in GRMustache, including the fact that it prevents the simple key "count" to return the number of elements in NSArray, NSSet, etc.

The solution was to detect those class very specifically, and to use the objc_msgSendSuper function. It allows to shunt the implementation of a given selector to the class you provide, particularly to NSObject. And suddenly NSArray has a value for key "count", so does NSSet, etc :-)

As a conclusion:

KeyValueCoding is a strange beast, that is not so badly done: taming it does not require much inner knownledge. I know many developers that try to do a better key-value-Observing. However key-value-Coding does not get much interest: maybe it is just really well done.

Fernando - 2013-02-08 22:17:20

Fri, 08 Feb 2013 22:17:20 GMT

It would be nice to mention how collections implement valueForKeyPath: and setValue:forKeyPath: to deal with collection and object operators (@sum, @avg, etc.).

Great article nonetheless.

Ian - 2013-02-08 16:00:35

Fri, 08 Feb 2013 16:00:35 GMT

@Nico: It occured to me... there is a mechanism to make LLDB aware of things 'after the fact'. You can set an 'expression parser prefix header' like this:

(llbd) set set target.expr-prefix /tmp/myheader.h

You could make it so that when your app generates these dynamic classes, it also writes a header file to some known location. Then you can tell LLDB to read this header from that location using the above command.

After doing that, I would expect that you would be able to call your dynamic class's methods from the LLDB expression parser without resorting to valueForKey: or any other tricks.

Ian - 2013-02-08 15:42:15

Fri, 08 Feb 2013 15:42:15 GMT

@Nico: The reason the debugger doesn't see it as a selector is that the debugger only knows about things that were available to it at compile-time. I believe if there were another object that had the same selector present at compile time, it *might* work. But AFAIK, the debugger's expression parser won't dig into the Objective-C runtime at expression-parse time. Someone please correct me if I'm wrong.

A way to prove this to yourself would be to do this: po objc_msgSend(o, NSSelectorFromString(@"property"))

If it works, that would show that the selector is definitively present, but that the debugger doesn't know about it.

Raphael - 2013-02-08 15:28:39

Fri, 08 Feb 2013 15:28:39 GMT

I think your setValue:forKey: code has a tiny mistake: [@"helloYou" capitalizedString] gives @"Helloyou", not @"HelloYou", so you won’t find the desired setter method…

Nico - 2013-02-08 15:27:42

Fri, 08 Feb 2013 15:27:42 GMT

Hello!

Great article! I have a book of yours that's full of them =P

I have a question (it may not be related to the subject of the article, sorry if that's the case) regarding dot syntax.

I wrote a small piece of code that, given an XML file with a certain format, dynamically creates a class for the object type described by it.

It works ok, but I was wondering why is it that, when using the debugger to query the properties, neither o.property nor [o property] works, but [o valueForKey:@"property"] does indeed work (this article helped me understand that it is because of the property->ivar->underscored ivar fallback).

When creating the class, I'm adding both ivars and properties for it.

I tried adding getter methods (just getters for now) in some sort of generic way but I can't seem to understand how to retrieve ivar values without going through the ivar list every time.

Any pointers on how I may enable such feature for my dynamically-generated classes? I know it may not be possible at all to use dot syntax, but I'm curious about the sending the getter message to the object.

Sorry if this is either too long, too offtopic or plainly too twisted to read!