> On Oct 18, 2014, at 23:38 , Roland King <r...@rols.org> wrote: > > > The very first of those errors looks like you had the code in the wrong > place, ie not within your class. > > Initialization is one of those Swift things which is uber-safe and thus very > structured and hence in practice annoying. > > You can read all the rules in the book but it boils down to everything goes > through the designated initializers at some point. That includes , in this > case, the convenience initializer init( windowNibName, owner ), the > implementation of that eventually calls one of the two designated > initializers, init( window: ) or init( coder: ). Those designated ones are > what you need to customize/orerride in your class to do any extra > initialization required. You can then still call init( windowNibName:, owner: > ) and eventually one of those two designated initializers will get called, > the ones you overrode. > > But, you cry, I only want to do some piece of work if init( windowNibName:, > owner: ) was the initializer called, I want to call super on that and then .. > I dunno .. log the name of the nib or something, but you can’t. You can > re-implement it, if you get all its side effects correct, but you can’t call > the superclass version. Nor do you know, when you finally get called in your > override of the designated initializer, how you got there. > > Oh and yes if you override any of the designated initializers then you have > to override all the required ones at least as you don’t inherit them any > more. Also, if you want to inherit the convenience initializers then you have > to have all the designated ones, so if you’ve overidden one then you have to > do the lot, whether or not they are required. > > confused yet? > > And that ‘not accessing self’ thing. That normally comes up when you need > self to do something to initialize a property, but you can’t because you > can’t call super anything until you have initialized your properties and you > can’t use self until you’ve called super. The usual .. technique .. is to > make that property optional, or implicitly unwrapped optional, set it to nil > so it’s set enough to call super, then you can use self to find what you > REALLY wanted it to be and set it again.
:-) The rules on initializers don't make sense to me, in all honesty. If you imagine that instantiating the base class by calling any of the initializers results in a completely instantiated object, the subclass should also be able to call any of the inherited initializers. But whatevs, I'm on to storyboards now. -- Rick Mann rm...@latencyzero.com _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
