Re: Subclassing Catch-22
Re: Subclassing Catch-22
- Subject: Re: Subclassing Catch-22
- From: Marco Scheurer <email@hidden>
- Date: Tue, 26 Apr 2005 22:05:11 +0200
On Apr 26, 2005, at 20:28, Todd Ransom wrote:
I have a controller class that has methods like this:
- (BOOL)doSomething;
- (NSString *)getInformationRequiredToDoSomething;
- (BOOL)doSomething {
NSString *info = [self getInformationRequiredToDoSomething];
...
}
Which works fine until I subclass. In my subclass I would like
doSomething to call super for a subset of possible actions. But
when I call super it calls [self
getInformationRequiredToDoSomething] and returns its own info, not
super's.
You are not calling procedures but sending messages.
And "sending a message to super" really means: "sending a message to
self, starting the search for the selector in the superclass".
So [super doSomething] will correctly send
getInformationRequiredToDoSomething to self and in all probability,
unless you've overriden doSomething in your subclass, this is just
the same as [self doSomething].
I thought this was a fairly common pattern in Cocoa -- overriding
super's methods to do something specific and deferring to super for
its own functionality. I feel like I am missing some simple rule
for safely subclassing that would prevent this problem. Is there a
way I can design these methods so I don't run into this problem?
This is not a "problem", just how all this is supposed to work: you
should read the section about self and super at http://
developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/
LanguageOverview/chapter_3_section_6.html .
marco
Marco Scheurer
Sen:te, Lausanne, Switzerland http://www.sente.ch
_______________________________________________
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