Re: KVO one-step listening but two-step notifying?
Re: KVO one-step listening but two-step notifying?
- Subject: Re: KVO one-step listening but two-step notifying?
- From: Michel Schinz <email@hidden>
- Date: Sat, 24 Dec 2005 11:22:47 +0100
Le 24 déc. 05 à 04:48, mmalcolm crawford a écrit :
On Dec 23, 2005, at 5:21 PM, Hamish Allan wrote:
True. I don't seem to be doing very well at coming up with
examples, but I still feel that something isn't quite right. If
it's important for me to notify observers of upcoming changes to
properties, why can't I receive such notifications myself? It
seems that this design doesn't allow for me to proxy data without
copying it.
I'm not sure I understand the problem.
Without wanting to speak for Hamish, I think the problem is as
follows: if you want to have a method in an object which serves as a
proxy for a method in another object, you should be able to write
something as simple as:
- (SomeType*)proxyMethod:(SomeOtherType*)parameter {
return [otherObject originalMethod:parameter];
}
The problem is that this proxy method does not behave like the
original one for KVO: you can't observe "proxyMethod" using KVO as
you could have observed "originalMethod" with KVO (well, you can
observe it but you won't get the appropriate notifications). If you
want to make the proxy method KV-observable, you have to cache the
return value of the original method in the proxy object, observe the
original method, etc. as we already discussed in this thread. This
seems to be a lot of work for a trivial proxy method.
What I would want is a mechanism similar to what one gets with
setKeys:triggerChangeNotificationsForDependentKey: but which would
work for properties of another object too. That is, in the above
example, I would like to be able to write the one-line proxy method,
and have a simple way to say that when "originalMethod" changes in
"otherObject", then "proxyMethod" also changes (i.e. it's a dependent
property). Currently all of this has to be done by hand and it
quickly becomes tiresome.
Michel.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden