Op 12-11-2010 12:13, Graham Cox schreef:
nil from NSDictionary means no value associated with the key (dictionaries cannot store 'nil' as a value) so this is your cue to go fetch. The problem is that the object on which -valueForUndefinedKey: is invoked is the dictionary, not your wrapper, and since you are not subclassing the dictionary, you won't get that message (and the default will simply throw an exception). So instead, the override to -valueForKey: in your wrapper is acceptable, in this case. But instead of invoking -valueForKey: on the dictionary, use -objectForKey: directly. That way, you get nil when there's no key instead of an exception.
Unfortunatly this does not seem to be true. I use valueForKey on the dictionary and for non-existing keys, nil is returned. No exception is thrown. This is not a major problem I think, as I can just test for nil as with objectForKey.
If you have properties that can legally be nil, you'll need to treat those differently, using some sort of marker object that means the property really should return nil (and hence can be stored in a dictionary). For example [NSNull null] is a valid object which means 'nil'. Basically, you can't use nil itself to mean two different things, both uninitialized and a legal value, and since NSDictionary reserves the use of nil to mean undefined, you have no choice but to deal with that in some way.
Fortunatly, this is not a problem, all my properties are non-nil.
@implementation MyWrapper - (id) valueForKey:(NSString*) key { id value = [myDictionary objectForKey:key]; if( value ) return value; [self beginFetchForKey:key]; // assume starts a thread or asynchronous task which calls -setValue:forKey: on completion return nil; // OK, we have no value to return yet. } - (void) setNilValueForKey:(NSString*) key { [myDictionary setObject:[NSNull null] forKey:key]; // substitute a valid object for nil values } Because this does not override -setValue:forKey: you get all the usual goodness that gives you, such as KVO notifications. As your thread sets the value using KVC any observers get notified of the value having been fetched automatically (if you are using a thread take care to set the value on the main thread so that all notifications take place on the main thread).
But if I do not override setValue:forKey: How does the KVC logic now that it should not try to call setValue:forKey: on my wrapper object, but on the enclosed dictionary instead? Do I not need to override setValue:forKey: and call [myDictionary setValue:forKey] there? just as with valueForKey:?
The override to -valueForKey: here does lose some of the 'special powers' that Ken alluded to, one of them being the treatment of a leading '@' in the key. If that matters, you need to emulate what NSDictionary's implementation does. But since you are really replacing NSDictionary's version with your own, which has already discarded the vast majority of NSObject's 'special powers' I can't see you are losing much in this case. It has the advantage that subclassing NS(Mutable)Dictionary is not required.
Just out of curiosity, what is the use of the @ operator? I can't find anything about it in the KVC Programming Guide.
Kind regards, Remco Poelstra _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com