• 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: Matt Neuburg <email@hidden>
  • Date: Mon, 17 Jul 2006 15:43:01 -0700
  • Thread-topic: KVO and the observeValueForKeyPath bottleneck

On or about 7/17/06 1:42 PM, thus spake "Chris Kane" <email@hidden>:

> On Jul 17, 2006, at 1:00 PM, Scott Anguish wrote:
>> On Jul 17, 2006, at 2:31 PM, Matt Neuburg wrote:
>>> <http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueObserving
>>> /Concepts/KVOBasics.html#//apple_ref/doc/uid/20002252-179866>
>>>
>>> (Interestingly, the comment in that example is completely different
>>> from the
>>> comment in the copy on my machine.) The code shown in the example
>>> will break
>>> if super is NSObject. So perhaps I should file a bug on the docs.
>>
>> Actually, that was why it says "if it implements it".  Now I
>> suppose one could argue that NSObject does implement it, but as
>> Chris said, it just throws.
>
> The problem with that would be that "if it implements it" can change
> over time.  Next month you change a superclass of the class to start
> listening for KVO notifications (perhaps you install a software update
> of the OS!), and ... your hard-coded knowledge of what the super class
> did and didn't do is no longer true.
>
> You can't just blindly call super, and face the exception (hmm, is the
> exception there for a reason? could be a clue), but if you don't you
> cut off your superclasses from receiving necessary KVO notifications,
> given the design.

And there's a memory management problem. The "context" is not automatically
retained. Therefore if ClassA provided a context, only ClassA knows whether
that context needs to be released (or what it means). Gosh, this looks
troublesome on *any* implementation.

So ClassB needs a way to distinguish the notifications that belong to it (so
that it can pass along those that don't). The only way I can think of to do
this is to include an unmistakeable token in the context. But what would
this be - a hard-coded string? Yuck. m.

--
matt neuburg, phd = email@hidden, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide - Second Edition!
http://www.amazon.com/gp/product/0596102119
Take Control of Word 2004, Tiger, and more -
http://www.takecontrolbooks.com/tiger-customizing.html
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/



 _______________________________________________
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

References: 
 >Re: KVO and the observeValueForKeyPath bottleneck (From: Chris Kane <email@hidden>)

  • Prev by Date: Re: NSView to NSImage
  • Next by Date: Re: Whats the verdict on Cocoaruby from others ?
  • Previous by thread: Re: KVO and the observeValueForKeyPath bottleneck
  • Next by thread: Re: KVO and the observeValueForKeyPath bottleneck
  • Index(es):
    • Date
    • Thread