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: Wed, 25 Feb 2009 19:00:35 -0000
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.
----- Original Message -----
From: "Quincey Morris" <email@hidden>
To: <email@hidden>
Sent: Wednesday, February 25, 2009 6:38 PM
Subject: Re: Subclassing with more restrictive initializers
On Feb 25, 2009, at 08:39, Andy Klepack wrote:
> Should PreferenceFile inherit from File despite the initialize
> behavior being undesirable? Is composition somehow more appropriate?
> Is this confusion the result of thinking about the problem from the
> wrong direction?
>
> Any advice about how to think about and approach this sort of design
> problem would be great.
Also see:
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_4.html#/
/apple_ref/doc/uid/TP30001163-CH22-SW5
which sort of contains an answer to your question:
"A class must also make sure that all inherited initialization methods
work. For example, if class A defines an init method and its subclass
B defines an initWithName: method ..., B must also make sure that an
init message successfully initializes B instances. The easiest way to
do that is to replace the inherited init method with a version that
invokes initWithName: ... Covering inherited initialization methods
makes the class you define more portable to other applications. If you
leave an inherited method uncovered, someone else may use it to
produce incorrectly initialized instances of your class."
In practice, though, I agree with Michael that leaving superclass
initializers "uncovered" is not a big problem, unless it exposes some
kind of security exploit.
_______________________________________________
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
_______________________________________________
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