Thread View: comp.sys.next.programmer
5 messages
5 total messages
Started by dobermanmike Mike Panzitta
Mon, 28 Sep 1992 06:23
isKindOf: and IsKindOfClassNamed: problems
Author: dobermanmike Mike Panzitta
Date: Mon, 28 Sep 1992 06:23
Date: Mon, 28 Sep 1992 06:23
25 lines
1128 bytes
1128 bytes
Has anyone noted these problems with the above methods: - First, in 2.x the second method was called isKindOfGivenName: and is now isKindOfClassNamed: in 3.0. No warning or anything that I'm aware of indicated this change, and there is no backwards compatibility. - Second, and more important, I have discovered in a program (actually interactively within GDB) this interesting phenomena: (gdb) print [aClassObject isKindOf:[Process class]] $6 = 0 (gdb) print [aClassObject isKindOfClassNamed:"Process"] $7 = 1 The second case is the one that is correct. Any answers or insight? Thanks in advance, -Mike -- Mike Panzitta Doberman Systems doberman!mike@uunet.uu.net (NeXTMail)
Re: isKindOf: and IsKindOfClassNamed: problems
Author: Alex Blakemore
Date: Mon, 28 Sep 1992 15:34
Date: Mon, 28 Sep 1992 15:34
14 lines
1067 bytes
1067 bytes
In article <1992Sep28.062357.11948@doberman.uucp> doberman!mike@esunix.sim.es.com writes:> >- First, in 2.x the second method was called isKindOfGivenName: and > is now isKindOfClassNamed: in 3.0. No warning or anything that I'm > aware of indicated this change, and there is no backwards compatibility. this and the other name changes are described in the developer release notes which are on line. rationale is provided. the behavior you found in gdb may make more sense after you read those notes. -- --------------------------------------------------- Alex Blakemore alex@cs.umd.edu NeXT mail accepted
Re: isKindOf: and IsKindOfClassNamed: problems
Author: Tim McClarren
Date: Wed, 30 Sep 1992 04:26
Date: Wed, 30 Sep 1992 04:26
23 lines
1560 bytes
1560 bytes
alex@cs.umd.edu (Alex Blakemore) writes: >In article <1992Sep28.062357.11948@doberman.uucp> doberman!mike@esunix.sim.es.com writes:> >>- First, in 2.x the second method was called isKindOfGivenName: and >> is now isKindOfClassNamed: in 3.0. No warning or anything that I'm >> aware of indicated this change, and there is no backwards compatibility. >this and the other name changes are described in the developer >release notes which are on line. rationale is provided. >the behavior you found in gdb may make more sense after you >read those notes. Well, I can't seem to find a rationale for the changes, although I did find them documented in ObjC.rtf in the Developer Release Notes. I am having the same problem as the original poster. And the Release Notes don't make the behavior any clearer to me. I should think that these things should both return YES or both return NO. Any other clues? -- Tim McClarren | "...a bajillion brilliant Jobsian lithium licks." timm@ncsa.uiuc.edu| (217)244-0015 |
Re: isKindOf: and IsKindOfClassNamed: problems
Author: Alex Blakemore
Date: Wed, 30 Sep 1992 05:46
Date: Wed, 30 Sep 1992 05:46
19 lines
1452 bytes
1452 bytes
In article <timm.717827168@xongmao> timm@xongmao.ncsa.uiuc.edu (Tim McClarren) writes: > Well, I can't seem to find a rationale for the changes, although I > did find them documented in ObjC.rtf in the Developer Release Notes. > I am having the same problem as the original poster. And the Release Notes > don't make the behavior any clearer to me. I should think that these > things should both return YES or both return NO. Any other clues? the difference between the IsKindOf and IsMemberOf methods (and their cousins that take class names instead of class objects as args) is how they handle subclasses. if an object x is an instance of class B (which is a subclass of A) then x is a kind of A but x is NOT a member of A. (x is both a kind of B and a member of B) for more info look in the concepts section on objective C or the reference for the class Object. -- --------------------------------------------------- Alex Blakemore alex@cs.umd.edu NeXT mail accepted
Re: isKindOf: and IsKindOfClassNamed: problems
Author: Tim McClarren
Date: Wed, 30 Sep 1992 21:32
Date: Wed, 30 Sep 1992 21:32
30 lines
1934 bytes
1934 bytes
alex@cs.umd.edu (Alex Blakemore) writes: >In article <timm.717827168@xongmao> timm@xongmao.ncsa.uiuc.edu (Tim McClarren) writes: >> Well, I can't seem to find a rationale for the changes, although I >> did find them documented in ObjC.rtf in the Developer Release Notes. >> I am having the same problem as the original poster. And the Release Notes >> don't make the behavior any clearer to me. I should think that these >> things should both return YES or both return NO. Any other clues? >the difference between the IsKindOf and IsMemberOf methods (and their cousins >that take class names instead of class objects as args) is how they handle subclasses. >if an object x is an instance of class B (which is a subclass of A) then >x is a kind of A but x is NOT a member of A. >(x is both a kind of B and a member of B) >for more info look in the concepts section on objective C or the >reference for the class Object. That's not what was being discussed, nor is it what you said in your former post. I was already well aware of the differences between the "isKindOf:" and "isMemberOf:" methods. So the questions still stands: where is the rationale documented, and why is gdb exhibiting this odd behavior? Anyone, anyone? -- Tim McClarren | "...a bajillion brilliant Jobsian lithium licks." timm@ncsa.uiuc.edu| (217)244-0015 |
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads