Re: Superclass Changing Wierdness
Re: Superclass Changing Wierdness
- Subject: Re: Superclass Changing Wierdness
- From: "Mike T. Miller" <email@hidden>
- Date: Mon, 17 Nov 2003 12:27:38 -0800
My guess would be that the individual classes are caching the selectors
so that when you use [super squak] you are asking the super class (A or
B) for the method whereas when you allow class C to to execute the
super squak it has already cached the selector from the first call.
Very weird abuse of the system! I'm sure there are all kinds of
interesting uses (inserting "interceptor" classes for monitoring, etc.)
-mike
On Nov 17, 2003, at 10:59 AM, Matthew Cox wrote:
Following up on a discussion on programatically changing the superclass
of a class, I wrote a brief program to see if it can be done. Yes it
can, but its odd! I decided this probably wasn't what the original user
was talking about, so I decided to start a new thread.
If you compile and run the program attached below, you'll get an output
something like this:
2003-11-17 13:40:29.146 OCRuntimeAbuse[446] Creating an instance of
ClassC
2003-11-17 13:40:29.148 OCRuntimeAbuse[446] Making it squak.
2003-11-17 13:40:29.149 OCRuntimeAbuse[446] This is an instance of
ClassA speaking.
2003-11-17 13:40:29.150 OCRuntimeAbuse[446] Do something really unholy.
2003-11-17 13:40:29.151 OCRuntimeAbuse[446] Switching the superclass of
ClassC from ClassA to ClassB!
2003-11-17 13:40:29.153 OCRuntimeAbuse[446] Making the first object
squak again.
2003-11-17 13:40:29.154 OCRuntimeAbuse[446] This is an instance of
ClassB speaking.
2003-11-17 13:40:29.155 OCRuntimeAbuse[446] Making a whole new object
squak.
2003-11-17 13:40:29.156 OCRuntimeAbuse[446] This is an instance of
ClassB speaking.
[demime 0.98b removed an attachment of type application/octet-stream
which had a name of main.m]
This seemed interesting, it worked, so I decided to simplify my code
and commented out the definition for squak in the ClassC
implementation. Low and behold, the program outputs:
2003-11-17 13:52:52.315 OCRuntimeAbuse[552] Creating an instance of
ClassC
2003-11-17 13:52:52.316 OCRuntimeAbuse[552] Making it squak.
2003-11-17 13:52:52.316 OCRuntimeAbuse[552] This is an instance of
ClassA speaking.
2003-11-17 13:52:52.317 OCRuntimeAbuse[552] Do something really unholy.
2003-11-17 13:52:52.317 OCRuntimeAbuse[552] Switching the superclass of
ClassC from ClassA to ClassB!
2003-11-17 13:52:52.317 OCRuntimeAbuse[552] Making the first object
squak again.
2003-11-17 13:52:52.317 OCRuntimeAbuse[552] This is an instance of
ClassA speaking.
2003-11-17 13:52:52.317 OCRuntimeAbuse[552] Making a whole new object
squak.
2003-11-17 13:52:52.317 OCRuntimeAbuse[552] This is an instance of
ClassA speaking.
For some reason, eliminating the explicit call to [super squak] causes
the method in the old superclass to be called. Now, I know apple never
meant for us to play with this kind of stuff, so I should expect odd
behavior, but why is it that when I explicitly call the superclass's
method, it goes to the new superclass, but when I don't, the old
superclass gets the call? Anyone have some insight? I'm still running
10.2.8; does this happen the same way on 10.3?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.