Re: wasting space?
Re: wasting space?
- Subject: Re: wasting space?
- From: "Shawn Erickson" <email@hidden>
- Date: Mon, 6 Oct 2008 14:16:11 -0700
On Mon, Oct 6, 2008 at 1:22 PM, Erik Buck <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden