On Mon, May 11, 2009 at 10:00 PM, Graham Cox <[email protected]> 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 protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
