Re: With What does Apple Swizzle the IsA-pointer in KVO?

FROM : Philip Mötteli
DATE : Fri Nov 23 19:09:14 2007

Am 23.11.2007 um 17:23 schrieb Jean-Daniel Dupas:
> Le 23 nov. 07 à 17:03, Philip Mötteli a écrit :

>> Am 23.11.2007 um 15:54 schrieb Clark Cox:
>>

>>> On Nov 23, 2007 5:42 AM, Philip Mötteli <Philip.<email_removed>> 
>>> wrote:

>>>>
>>>> Apple says, that it uses IsA-swizzling as the underlying 
>>>> technology to
>>>> implement KVO.
>>>> What are/is the class(es), which replace the original class of the
>>>> observed object? Is it an NSProxy subclass? Different NSProxy
>>>> subclasses, depending on the observed object? Is it a direct 
>>>> subclass
>>>> of the observed object?

>>
>>

>>> Perhaps I could provide more help if you
>>> stated why it is that you think that you need to know this.

>>
>> I need to know, when an object has changed and I would prefer to 
>> reuse as much as possible, of what KVO already offers.
>> Unfortunately, KVO is based on the internals of an object (which 
>> should be assumed as being hidden in OOP). So if I want to observe 
>> an object that either doesn't have any declared IVar, like e. g. 
>> NSString and many others, or does not have a corresponding IVar, 
>> because it is not a simple setter method, like -finalize or -
>> dealloc, I have a problem.
>> Ideally, I just want to implement a plug-in, that reuses the 
>> functionality, offered by KVO, but extends it, so that the publicly 
>> accessible part of an object can be observed instead of the hidden 
>> internals.
>> I presume, I can do that, by implementing my own proxy, that 
>> prevents KVO to do an IsA swizzling, by implementing -
>> automaticallyNotifiesObserversForKey:. But I would have liked to 
>> reuse the method forwarding mechanism of KVO.
>>

>
> KVO is not based on the internals of an object (which is assumed to 
> be hidden), and it does not access hiddden internals. KVO is based 
> on KVC and uses accessors.


In order to use KVO, you need to know this famous "key". The key is 
the name of an instance variable, which is an object's internal data. 
Every OOP book will tell you that ():

> An object’s data is protected and won’t be touched by any other part 
> of the program. Methods can therefore trust its integrity. They can 
> be sure that external access hasn’t put it in an illogical or 
> untenable state.