Re: Subclassing Catch-22
Re: Subclassing Catch-22
- Subject: Re: Subclassing Catch-22
- From: Todd Ransom <email@hidden>
- Date: Tue, 26 Apr 2005 14:20:04 -0600
I never said it was a problem or a bug in Cocoa. I know this is how
it's supposed to work. I am asking if anyone knows of a pattern or
method that would help me avoid this type of situation.
Todd Ransom
Return Self Software
http://returnself.com
On Apr 26, 2005, at 2:05 PM, Marco Scheurer wrote:
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