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 protected]> To: <[email protected]> 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 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/p.sanders%40dsl.pipex.com This email sent to [email protected] _______________________________________________ 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]
