Re: Subclassing NSWindowController in Swift
Re: Subclassing NSWindowController in Swift
- Subject: Re: Subclassing NSWindowController in Swift
- From: Roland King <email@hidden>
- Date: Sun, 19 Oct 2014 14:38:20 +0800
> On 19 Oct 2014, at 11:42 am, Rick Mann <email@hidden> wrote:
>
>
>> On Oct 18, 2014, at 20:33 , Graham Cox <email@hidden> wrote:
>>
>> According to the latest documentation pack that arrived on Thursday, Swift has:
>>
>> convenience init(windowNibName windowNibName: String,
>> owner owner: AnyObject)
>>
>> So just use this. Like C++, Swift has overloaded method names, so 'init' can take various parameter combinations.
>
> I tried this:
>
> 16 override
> 17 init()
> 18 {
> 19 init(windowNibName: "foo", owner: self);
> 20 }
> 21
>
> But I get:
>
> /Users/rmann/Projects/XCAM/repo/XNC/trunk/XNC/CommConfig.swift:19:7: Initializers may only be declared within a type
> /Users/rmann/Projects/XCAM/repo/XNC/trunk/XNC/CommConfig.swift:19:23: Expected parameter type following ':'
> /Users/rmann/Projects/XCAM/repo/XNC/trunk/XNC/CommConfig.swift:19:23: Expected ',' separator
> /Users/rmann/Projects/XCAM/repo/XNC/trunk/XNC/CommConfig.swift:21:1: 'required' initializer 'init(coder:)' must be provided by subclass of 'NSWindowController'
>
> If I instead call super.init(...), I get:
>
> /Users/rmann/Projects/XCAM/repo/XNC/trunk/XNC/CommConfig.swift:19:3: Must call a designated initializer of the superclass 'NSWindowController'
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.
_______________________________________________
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