Re: quick and dirty NSData implosion
Re: quick and dirty NSData implosion
- Subject: Re: quick and dirty NSData implosion
- From: Graham Cox <email@hidden>
- Date: Tue, 12 May 2009 12:00:57 +1000
On 12/05/2009, at 11:36 AM, Adam R. Maxwell wrote:
On May 11, 2009, at 6:11 PM, Graham Cox wrote:
On 12/05/2009, at 6:20 AM, jon wrote:
- (id)initWithCoder:(NSCoder *)c
{
[super init];
You do not and should not call [super init] here. In this case it's
harmless as it happens, but in the general case it's not. The only
thing initWithCoder is obliged to call is super's -initWithCoder:
and ONLY when the object is not an immediate subclass of NSObject.
In this case it is, so you should remove this line.
Can you point to documentation on that? The only thing I've seen
says "If the superclass of your class does not support NSCoding, you
should invoke the superclass’s designated initializer instead of
initWithCoder:."
http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/Archiving/Tasks/codingobjects.html#/
/apple_ref/doc/uid/20000948
Ah, yes, I think what I'm saying can be misinterpreted. If you inherit
from an object that implements NSCoding, your -initWithCoder: should
call super's -initWithCoder:, but NOT super's designated (or any
other) initializer. So in fact the OP's code is right, since NSObject
doesn't implement NSCoding, though in that case we know NSObject's
designated initializer doesn't do anything so it makes no difference
whether it's there or not. In the interests of correctness though, it
should be there, so I retract my advice.
What's a slight nuisance with this rule is that if I change what my
class inherits from, I will have to revisit my -initWithCoder: method
to possibly call super's initWithCoder: instead of super's designated
initializer. If my method was calling [super init] on NSObject, that
perfectly harmless call may now become harmful in the case I neglect
to revisit that code. A more benign situation would be where NSObject
implemented NSCoding but to be a no-op, then there would be one
consistent rule for all initWithCoder: methods that was independent of
the ancestry of the class. But that isn't the case so we're stuck with
it I guess.
I think the situation where you have an object supporting NSCoding
that inherits from something that doesn't, but isn't NSObject itself,
is going to be pretty unusual.
--Graham
_______________________________________________
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