Re: Key Value Observation is over reacting

[Fred Kiefer]

Richard Frith-Macdonald wrote:
> On 2007-12-13 17:34:34 +0000 Fred Kiefer <address@hidden> wrote:
> 
>> While testing key value binding I found a problem with the current KVO
>> code. When an object is starting to get watched a new class gets cooked
>> up to handle the set calls on the object. Here all setter methods get
>> overridden, which is fine, as we don't want to change the class when
>> another key on the same object gets watched and this also allows to
>> reuse the new class for other objects.
>> But some of the replaced methods just don't are setters, even if the
>> look like. This later leads to a problem when the corresponding getter
>> is called and none exists. Here we should at least check, if a getter
>> exists and only then treat the method as a setter.
>> Is it OK, to change that code or is there something I overlooked?
> 
> I'm not sure ... while it does not sound unreasonable that every setter
> must have a corresponding getter, neither does it sound obviously true
> to me.  I would suggest writing a testcase to determine what methods are
> overridden, and running it on MacOS-X before going any further ... best
> to try to make sure that our implementation has the same behavior as
> Apple's.
> 
> It may be that Apple check for the presence of a getter immediately
> before using it rather than at the point when the subclass is created.
> 

I am not sure what the benefit of this approach would be. Wont that
result in methods being overridden, that will never be called successfully?
In my case I have a method setSomethingOnMain: that calls setSomething:
in the main thread. This fails when the class is being watched as there
is no way to get the value for somethingOnMain.
The solution I wanted to implement would be to just look of there is a
method somethingOnMain or _somethingOnMain and only replace
setSomethingOnMain: if that method exists. This does of course not cover
the full scope of key value coding, but is the only thing I see that we
could do at that time.
Your proposal is to wait until the change happens and the search for the
getter fails, but what should we do then? Isn't it to late to back out?

As you are more experienced in this area, I would like to leave the
decision which path to take to you. As for the test on Apple, how would
I find out which way they take? 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?