RE: NSXMLParser bug?
RE: NSXMLParser bug?
- Subject: RE: NSXMLParser bug?
- From: "Karan, Cem (Civ, ARL/CISD)" <email@hidden>
- Date: Fri, 12 Sep 2008 13:15:00 -0400
- Thread-topic: NSXMLParser bug?
<SNIP>
> > 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).
That is actually how I read it; that even if the object can't do
anything useful (e.g. [[NSNumber alloc] init]), it shouldn't crash when
it receives a release message. For objects that require some kind of
initialization to work right, I keep a boolean around that signals if
the instance was properly initialized. My class's designated
initializer knows how to set that properly, but the superclasses don't,
and if you call a method without correctly initializing the instance, an
exception is raised telling you why you can't do that. This isn't
ideal, but it works fairly well in practice.
Thanks,
Cem Karan
_______________________________________________
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