• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: KVO and the observeValueForKeyPath bottleneck
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: KVO and the observeValueForKeyPath bottleneck


  • Subject: Re: KVO and the observeValueForKeyPath bottleneck
  • From: Chris Kane <email@hidden>
  • Date: Mon, 17 Jul 2006 11:24:04 -0700

On Jul 17, 2006, at 10:49 AM, Matt Neuburg wrote:
On Mon, 17 Jul 2006 09:09:04 -0700, Chris Kane <email@hidden> said:
On Jul 17, 2006, at 7:38 AM, Matt Neuburg wrote:

On or about 7/17/06 3:38 AM, thus spake "Jakob Olesen"
<email@hidden>:

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)
object change:(NSDictionary *)change context:(void *)context
{
     if ([self respondsToSelector:(SEL)context])
         [self performSelector:(SEL)context withObject:change];
}

By an incredible coincidence, yesterday (before this reponse arrived at my desk), after considering all the responses I'd gotten, I decided upon an approach and implemented it in my app, and it was word for word, letter for letter identical with this. m.


I'm just curious ... with the trivial approach above, and the other
ones involving the context being a keypath and so on ...  has anyone
considered what will happen if a superclass or subclass (of whatever
class that is) is also doing KVO (on either same or different keys)
of the same objects?

I hadn't, but I presume you wouldn't be asking the question unless the
answer were, "Something bad...?" :) I guess you're hinting that one needs to
call super.

No, I wasn't thinking that. Though having to call super could still be a valid conclusion.


Simply calling super would be problematic, because NSObject doesn't implement it (well, it throws).

No, I was pondering something more subtle to do with the context. The basic "shunting" pattern here that is somewhat popular is fundamentally broken, I think, because people are not considering subclassing, and I wonder if the circumlocutions to avoid the problem are worth the trouble.


The thing I'm really wondering is: Why was KVO implemented in this oddly
bottleneck-based way? There is terrific prior art, in the form of ordinary
notifications and the notification center (broadcaster-type architecture);
is there some technical reason why KVO doesn't use that?

I'm going to have to leave you hanging on these...



Chris Kane
Cocoa Framework, Apple


_______________________________________________ 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
  • Follow-Ups:
    • Re: KVO and the observeValueForKeyPath bottleneck
      • From: Matt Neuburg <email@hidden>
References: 
 >Re: KVO and the observeValueForKeyPath bottleneck (From: Matt Neuburg <email@hidden>)

  • Prev by Date: Re : Newbie Q : using a framework
  • Next by Date: Re: Pull-down menu weirdness
  • Previous by thread: Re: KVO and the observeValueForKeyPath bottleneck
  • Next by thread: Re: KVO and the observeValueForKeyPath bottleneck
  • Index(es):
    • Date
    • Thread