[bug #22246] problem with key value observation

[Fred Kiefer]

Follow-up Comment #6, bug #22246 (project gnustep):

Your change reduced the amount of get calls from three to two. What happens
shouldn't be too hard to understand. Instead of calling three overriden
methods the code now calls two, setValue:forKey and the real setter method.

As we have two calls for the same key in one call stack, the behaviour that I
diagnozed in my last entry still persists. The overriden code in
setVale:forKey: sets up a change for this key, next it calls the original
method, this calls the overriden setter, here again a change gets set up for
the key (overriding the previous change for the same key). Then this method
calls the original setter, next it gets the new value and sends the change
notification. Finally it resets the change info to nil. The stack gets
unrolled up to the overriden setValue:forKey:, here we try to send another
change notification, but now the change info is nil, so all the values we get
here are lost and nil is send as change.

What is a bit harder to say is, what the actual expected behaviour should
look like. We should of course only send one change notification, but should
that come from the overriden setter or from the overriden setValue:forKey
method? I think Apple only uses the setter, but doing it in the
setValue:forKey: method could be easier to implement. We would just check,
whether there is already a change info stored for the current key and not
process any notification stuff. That works nicely with any amount of overriden
methods on the call stack.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22246>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/