-------- Original-Nachricht --------
Datum: Fri, 14 Dec 2007 02:11:02 +0100
Von: Markus Hitter <address@hidden>
An: Fred Kiefer <address@hidden>
CC: GNUstep Developer <address@hidden>
Betreff: Re: Key Value Observation is over reacting
Am 13.12.2007 um 21:12 schrieb Fred Kiefer:
I just see that this special case is not
failing there. Should I set breakpoints on methods of the watched
instance and check the back trace for on the fly methods?
Yes, why not?
As for the remaining part, I can't see when the getter method would
be
used inside KVO at all. Notifications are sent on value changes
only,
which does the setter. Where does the conflict arise?
It is when the KVO code tries to get the value for the key before the
change
(and also after, but it doesn't get that far). To get the value it
uses the
valueForKey: method and this fails with an unknown key (OK, the
details are a
bit more complex, but it boils down to this).
Until today, I always thought KVO is based on a mini notification
center
inside NSObject's -setValue:forKey:. This method would try a few
ways to
get the variable set, then send a notification to all subscribers
on
success. No need to patch existing classes.
This is only enough for changes done via the setValue:forKey: method,
what
about normal setter methods, the ones I have this issue with?
However, this morning I learned, Apple uses something they call
"isa-
swizzling":
<http://developer.apple.com/documentation/Cocoa/Conceptual/
KeyValueObserving/Concepts/KVOImplementation.html#//apple_ref/doc/uid/
20002307>
This is more or less what GNUstep does as well. It is just the
details, which
methods will be replaced at which time that make a difference.
GNUstep is
rather eager at replacing methods. Perhaps we should just replace
them when
they are actually being watched at least on one object?