Re: KVO and isKindOfClass:
Re: KVO and isKindOfClass:
- Subject: Re: KVO and isKindOfClass:
- From: Philip Mötteli <email@hidden>
- Date: Fri, 18 Mar 2005 10:15:59 +0100
Am 18.03.2005 um 09:59 schrieb John C. Randolph:
On Mar 17, 2005, at 1:34 PM, Greg Titus wrote:
On Mar 17, 2005, at 1:26 PM, mmalcolm crawford wrote:
On Mar 17, 2005, at 11:52 AM, Timothy J.Wood wrote:
But, if this is sent to an object that has been targeted for KVO,
it's isa gets replaced with NSNotifying_MyClass which is NOT a
subclass of MyClass, but instead appears to be a clone of MyClass.
This seems to me to be a pretty big bug in KVO, but I'm wondering
if there is some design reason for this that I'm not considering.
Yes: It means that for most people, all they have to do is to
implement standard accessor methods and their class is instantly KVO
compliant. This means that many classes written for 10.2 and
earlier will be automatically KVO compliant, which makes things easy
for many people. If, however, you depend on exact class identity,
or have some other reason not to want your class swizzled out from
under you, then you should just use manual KVO.
I understand the use for swizzling the isa pointer. What I don't
understand is why NSNotifying_MyClass is _not_ a subclass of MyClass,
which is what is breaking Tim's code. What's the reason for that?
We need the notifying posers to behave consistently, which we can't
ensure if they might happen to be derived from any class in your app.
What about returning the original class?
Re
Phil
_______________________________________________
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