Re: Subclassing NSWindowController in Swift
Re: Subclassing NSWindowController in Swift
- Subject: Re: Subclassing NSWindowController in Swift
- From: Rick Mann <email@hidden>
- Date: Sat, 18 Oct 2014 23:46:21 -0700
> On Oct 18, 2014, at 23:38 , Roland King <email@hidden> 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
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