Re: Behavior of autoreleased window controller for closing window vs. app termination
Re: Behavior of autoreleased window controller for closing window vs. app termination
- Subject: Re: Behavior of autoreleased window controller for closing window vs. app termination
- From: James DiPalma <email@hidden>
- Date: Tue, 1 Oct 2002 09:54:56 -0400
From: Alan Nilsson <email@hidden>
From: James DiPalma <email@hidden>
A suggestion (that will not change anything about how your code works)
is to change this method:
Just out of curiosity, why?
Your initWithPersonID: method contained this line of code:
self = [super initWithWindowNibName:@"User2"];
Because your subclass of NSWindowController does not implement
initWithWindowNibName:, calling [self initWith...] is going to end up
calling [super initWith...]. So execution of your subclass's instances
will not change.
If you ever right a subclass of your NSWindowController subclass,
UserController, you may want to override initWithWindowNibName:. In
this case your new subclass, UserControllerSubclass, will probably
still init with a call to initWithPersonID:, but your call to [super
initWithWindowNibName:] will now refer to UserController, because super
is dynamic: a UserControllerSubclass instance's superclass is
UserController (and not NSWindowController as I think it would be in
C++) even though you are referencing super in UserController's code.
So, UserControllerSubclass's initWithWindowNibName: would not get
called by UserController's initWithPersonID: even though you might want
it to.
I recommend that you make this change to show how you might benefit
from writing your init methods this way (someday you will write a
subclass of a subclass). And maybe to help you understand/reinforce
what you may or may not already know.
That explains why I recommended using self; hopefully you understand
what I said and you can choose to agree or disagree. Taking one step at
a time, there is another interesting point that builds on my previous
recommendations:
Designated initializers are defined in NSObject's documentation under
-init. If you look at NSWindowController, it has a few init methods:
- initWithWindow:
- initWithWindowNibName:
- initWithWindowNibName:owner:
- initWithWindowNibPath:owner:
-initWithWindow: is its own designated initializer for when
NSWindowController is only a window controller. -initWithWindowNibName:
calls initWithWindowNibName:owner: (with self as owner), which does not
call -initWithWindowNibPath:owner:. So, NSWindowController has 3
designated initializers.
Designated initializers have a complete set of information used to
initialize an object; a subclass will sometimes also need access to
this set of information during initialization. So, subclasses can help
future subclasses by having a designated initializer that has this same
set of information.
If you understand these statements, you can again choose to agree or
disagree with this suggestion:
- (id) initWithWindowNibName:(NSString*)name owner:(id)owner
personID:(int)pid
{
self = [super initWithWindowNibName:name owner:owner];
return self;
}
- (id) initWithPersonID:(int)pid
{
return [super initWithWindowNibName:@"User2" owner:self personID:pid];
}
-jim
_______________________________________________
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.