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 19:35:08 -0800
On Feb 10, 2008, at 18:28, Bill Bumgarner wrote:
-- Someone did an automated check of every Cocoa class in Tiger
(maybe it was every subclass of NSObject, I don't remember exactly
now) and counted the number of classes for which the receiver of
[super init] was different from the returned value. The answer was 0.
That may comfort anyone who wants to leave out the 'self =', but
it's hardly a reliable argument. The number of dead people reading
this discussion is also 0 (afaik), but I wouldn't take that as
proof of immortality.
It would be impossible to test every conceivable set of arguments.
For example, NSData may return instances of different classes
depending on how large a chunk of memory is desired or if it is a
memory mapped vs. malloc()d chunk o' bits.
Similarly, this is entirely an implementation detail. Any given
class may return a subclass at some future time when it doesn't
now. Or it might even return a different class on a different
architecture -- 32 bit vs. 64 bit, for example.
You (and Jens) are perfectly correct. If I sounded like I thought this
automated check was anything but snake oil, I expressed myself badly.
-- Some classes cannot be subclassed -- cluster classes like
NSArray, for example. These classes prove nothing one way or
another about writing subclass initializers.
Class clusters can be subclassed just fine and, while not terribly
common, there are some very good reasons for doing so.
Well, you're right and I'm wrong.
But that just makes NSArray even less relevant to the 'self = [super
init]' question.
'[[NSArraySubclass alloc] init]' sends the init message to an actual
instance of NSArraySubclass. The subclass init method (according to
the Cocoa discussion of NSArray subclassing I just checked) should
send [super init]. There's nothing special about this, and it's not
going to answer whether 'self =' is needed.
(My mistake was in assuming that the substitution of a private class
occurred inside -[NSArray init]. If it did, you would not be able to
subclass NSArray. Apparently, the substitution occurs inside +[NSArray
array...]. My only defense is that everyone else except you who used
the NSArray example seems to have made the same mistake.)
Either way, an example based on NSArray doesn't give any information
about the need for 'self ='.
But, no matter ...
On Feb 10, 2008, at 17:49, mmalc crawford wrote:
<http://developer.apple.com/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObject_Class/Reference/NSManagedObject.html#//apple_ref/occ/instm/NSManagedObject/initWithEntity:insertIntoManagedObjectContext:
>
Hooray, a bona fide clincher! :)
_______________________________________________
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