Re: Subclassing with more restrictive initializers
Re: Subclassing with more restrictive initializers
- Subject: Re: Subclassing with more restrictive initializers
- From: "Paul Sanders" <email@hidden>
- Date: Thu, 26 Feb 2009 14:36:43 -0000
Oh yes, that's a good idea. Thanks.
----- Original Message -----
From: "Ken Thomases" <email@hidden>
To: "Paul Sanders" <email@hidden>
Cc: <email@hidden>
Sent: Thursday, February 26, 2009 5:27 AM
Subject: Re: Subclassing with more restrictive initializers
On Feb 25, 2009, at 1:00 PM, Paul Sanders wrote:
> My solution would be to cover *all* inherited initialisers and
> assert in any
> not supported by the subclass. The idea, surely, is to catch any
> programming errors as early as possible. Not covering an
> initialiser which,
> if called, would lead to unpredictable results seems to me to be
> taking an
> unnecessary risk (of introducing a bug).
>
> *Now* all we need is an implementation of assert that does something a
> little more useful than SIGABRT. But that is a detail.
Apple's recommendation when a subclass wants to "disavow" a method of
its superclass is to have the subclass override invoke [self
doesNotRecognizeSelector:_cmd].
Cheers,
Ken
_______________________________________________
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