Re: self = [super init] debate.
Re: self = [super init] debate.
- Subject: Re: self = [super init] debate.
- From: Ricky Sharp <email@hidden>
- Date: Sun, 10 Feb 2008 14:01:25 -0600
On Feb 10, 2008, at 1:29 PM, Quincey Morris wrote:
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.
I agree with what Quincey says here. I know when I first started
Cocoa, my inits were a bit different. But, after reading many things
(mostly from this list), I opted to keep all my inits in the following
form:
if ((self = [super init]) != nil)
{
[self setPropertyA:someValue];
[self setPropertyB:...
}
return self;
The way I look at this, it may be that this pattern is overkill for
many situations, but I've yet to see a case where this pattern is the
wrong thing to do. And by wrong, I don't mean saving a few keystrokes
in typing; wrong in that some compile and/or runtime issue will come
up. I'd rather spend my time writing business-logic code than
attempting to figure out just what init pattern may save me on typing
and/or a few compute cycles.
Thus, I use this single pattern since I know it will work in all
cases. I also like more explicit code anyhow. Even in Java, my
constructors are usually like:
int x;
int y;
public foo(int anX, int aY) {
this.x = anX;
this.y = aY;
}
It's not necessary to use 'this', yet I prefer to always do that to me
more explicit.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
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