Re: NSXMLParser bug?
Re: NSXMLParser bug?
- Subject: Re: NSXMLParser bug?
- From: Graham Cox <email@hidden>
- Date: Fri, 12 Sep 2008 20:55:37 +1000
On 12 Sep 2008, at 7:30 am, Ken Ferry wrote:
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
So, what you're saying is that the OP was right - init *should* be
overridden to call the designated initializer if init itself isn't it.
In that case it would appear that NSXMLParser does indeed have a bug.
It also suggests that the documentation which I linked needs to
clarify this because it's not explicitly stated.
By the way, the operative word with my comment regarding NSView was
"effective". I can see that init can just pass a zero rect, but does
that make a useful view? No, not really - but perhaps I miss the point
a bit there. The idea is to return an object that is viable, and won't
crash, right? Not one that is actually useful (without further set up).
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?
_______________________________________________
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