On Mon, Oct 6, 2008 at 1:22 PM, Erik Buck <[EMAIL PROTECTED]> wrote: > I am no fan of KVO or bindings, but I disagree with Mike Ash on his analysis. > > If you are even tempted to override - (void)observeValueForKeyPath:(NSString > *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void > *)context, you have missed the whole point of KVO IMHO. > > Let the built in framework code parse the key paths. You should forget that > key paths even exist.
I am confused on how the remainder of your post related to what Michael posted about. If you want to create objects that support KVO and write code that observes properties of those objects then the pathway that observers have to get "notifications" is via observeValueForKeyPath: ofObject:change:context: (unless you are binding properties of the observed to a property of the observer, aka KVB). Of course attempting to override the observeValueForKeyPath:... method of a nontrivial Apple provided class is questionable (depending on the context and what you are attempting to do) but in your own code it is reasonable thing to do. For example I have a set of model objects that support KVO/KVC for a sub-set of properties. I have (read-only) UI that are bond to these model objects directly using the framework provided controller layer and IB support for bindings. This is nice and simple, no code to have my UI be updated to reflect the state of the model. However I also have other objects that need to observe changes to some of these same properties and since they already support KVO the observers leverage KVO (why reinvent a KVO of my own) and as a result have the type of logic that Michael denotes (switch statement | if/else tree) in observeValueForKeyPath:... to handle change "notification". I agree with Michael on this aspect of things it can get a little ugly. -Shawn _______________________________________________ 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 [EMAIL PROTECTED]
