Re: quick and dirty NSData implosion
Re: quick and dirty NSData implosion
- Subject: Re: quick and dirty NSData implosion
- From: Michael Ash <email@hidden>
- Date: Tue, 12 May 2009 01:00:47 -0400
On Mon, May 11, 2009 at 10:00 PM, Graham Cox <email@hidden> wrote:
> 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.
You *always* have to revisit *all* of your initializers any time you
change superclasses. The available initializers and the designated
initializer(s) vary from one class to another. There's no change-free
approach available here. Even a no-op -initWithCoder: on NSObject
wouldn't save you, because what if you switched your superclass to
something which doesn't implement NSCoding but which requires an
initializer other than plain -init?
If you want to make your code more robust, you can always do an
if([SuperClass instancesRespondToSelector:_cmd]) check, but that's
still not foolproof due to the potential for needing another
initializer like I said.
Mike
_______________________________________________
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