Re: NSXMLParser bug?
Re: NSXMLParser bug?
- Subject: Re: NSXMLParser bug?
- From: "Ken Ferry" <email@hidden>
- Date: Thu, 11 Sep 2008 14:30:24 -0700
On Thu, Sep 11, 2008 at 2:23 PM, Ken Ferry <email@hidden> 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@hidden> 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 (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