On Thu, Sep 11, 2008 at 2:23 PM, Ken Ferry <[EMAIL PROTECTED]> wrote: > Hi Graham, > > That's backwards.. only subclassers are concerned with designated > initializers. Someone creating an object can call any init method. > > Maybe it's easiest to describe by intent. > (1) Every class has at least one, and possibly more, designated initializers. > (2) When an object is created, exactly one of the designated > initializers at every level of the class hierarchy should execute. > > You can figure out your responsibilities from the intent. If you have > initialization that needs to be done, > (1) You must override every designated initializer of your superclass. > (2) The designated initializers of _your_ class are the ones that call > a super with an init method that is a designated initializer of the > superclass. Your designated initializers needn't have any > relationship to the designated initializers of your superclass (i.e., > neither a subset nor a superset). > > If you add a new designated initializer to a class, you introduce a > new responsibility to all of your subclassers, so it's to be avoided > in frameworks. It's easy to avoid by calling [self someInitMethod] > instead of [super someInitMethod] when you introduce a new init > method, or by calling super with some method that is not a designated > initializer of the superclass. > > See also James Dempsey and the breakpoints, "Designated Initializer". > <http://www.youtube.com/watch?v=ajlESsRXqmM>. > >> For some classes (NSView springs to mind) I can't see an >> effective way that init could be overridden for all possible classes. > > - (id)init { > return [self initWithFrame:NSZeroRect]; > }
Actually, maybe this example is exploring. What does this do? Well, init is a designated initializer of NSView's superclass, NSResponder. However, with this implementation, -init is not a designated initializer of NSView. If someone calls [[NSView alloc] init], you'll see this sequence of calls: [NSView init] - not designated [NSView initWithFrame] - designated [NSResponder init] - designated [NSObject init] - designated This is the usual pattern at init. Let's say a user calls a non-designated initializer. That may call other non-designated initializers, but at some point one of those will call self with something that is a designated init method of the leaf class. That method will call [super aDesignatedInitializerOfTheNextClassUp] and so on, all the way to the root. Then the whole mess returns. -Ken > > There are some classes that override some init methods to throw, but > that breaks polymorphism a bit. People don't pass around classes that > much, so it's usually not too bad in practice. > > -Ken > Cocoa Frameworks > > On Thu, Sep 11, 2008 at 6:09 AM, Graham Cox <[EMAIL PROTECTED]> wrote: >> >> On 11 Sep 2008, at 10:50 pm, Karan, Cem (Civ, ARL/CISD) wrote: >> >>> I thought that all initializers had to call through the designated >>> initializer, which means that init should be overridden to call >>> initWithData:. Am I wrong? >> >> >> Re-reading the docs: >> >> file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_6.html >> >> I don't see any requirement that init must be overridden to call the >> designated initializer, only that clients of a class must use the designated >> initializer. For some classes (NSView springs to mind) I can't see an >> effective way that init could be overridden for all possible classes. (That >> said I often do try to do this for my home-grown classes, so that calling >> plain -init usually gives you something that works). >> >> Anyway try passing a dummy data object - does the crash go away? >> >> >> G. >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> 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/kenferry%40gmail.com >> >> This email sent to [EMAIL PROTECTED] >> > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
