Re: self = [super init] debate.
Re: self = [super init] debate.
- Subject: Re: self = [super init] debate.
- From: Quincey Morris <email@hidden>
- Date: Sun, 10 Feb 2008 11:29:16 -0800
On Feb 10, 2008, at 09:18, Scott Andrew wrote:
-(id) init
{
self = [super init];
if (self != nil)
{
.. do my init
}
return self;
}
So my question is:
As i get ready to teach non-cocoa programmers in my company about
cocoa programming, and having read Will Shipley's blog, Is the above
the way to teach writing an initializer? I see Will, and a few
others, say no [super init] will initialize self in its code there
is no reason to assign self. Yet all code and docs I see have
similar code.
The short answer: do the assignment to 'self'; it's wrong to omit it.
The long answer:
You can't rely on the discussion in the comments section of Shipley's
blog, because it's effectively all off-topic. (Well, half of it is
just plain wrong, and the rest of it is stuck on an irrelevant
example.) Shipley's argument is basically this: if X is a subclass of
Y, and the [super init] in X's init returns something other than an
instance of X (partially initialized by Y's init), then the subclass
can't work -- where would the subclass's instance variables be, for
example? -- therefore, the [super init] must in fact return the
instance you sent the [super init] to.
That discussion was using something like NSArray as an example, since
"creating" a NSArray actually creates a private class instance. So you
write:
@interface ArraySubclass : NSArray {
int myIvar;
}
...
- (id) init {
self = [super init]; // assume this returns a private class instance
...
myIvar = 5; // oops -- the private class doesn't have this
}
Shipley tried to conclude from this that the "self =" assignment was
at fault. In fact, what the example actually shows is that you cannot
usefully subclass NSArray (or any other class cluster like it). That's
why there are pages of Cocoa documentation explaining what to do
*instead of* mistakenly subclassing NSArray.
Slightly more generally, it shows that there is a *condition* for a
subclass to be legal: the result of its calling [super init] must be
something that works as a partially initialized instance of the
subclass. If you're not sure of that, don't try to subclass.
The other flaw in Shipley's conclusion is that, even if X's [super
init] returns an instance of X, it may not be the instance you sent
the [super init] to, so you'd better remember the returned value.
For example, it's not hard to imagine that the superclass Y's init
might copy the instance to a different memory zone and return the
copy. Y might need some knowledge of objective C internals to make
something like that feasible, but Apple tells us to assume that a
different instance might be returned, so it seems wise to believe them.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden