> On 19 Oct 2014, at 11:42 am, Rick Mann <rm...@latencyzero.com> wrote:
>
>
>> On Oct 18, 2014, at 20:33 , Graham Cox <graham....@bigpond.com> 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 (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
