Re: Throwing an error from a NSDocument.init override
Re: Throwing an error from a NSDocument.init override
- Subject: Re: Throwing an error from a NSDocument.init override
- From: Quincey Morris <email@hidden>
- Date: Wed, 15 Feb 2017 10:04:48 -0800
On Feb 15, 2017, at 00:29 , Daryle Walker <email@hidden> wrote:
>
> Apple’s code will call my versions instead of the ones in NSDocument, right?
Yes, because your subclass initializers are (from the Obj-C perspective) overrides, or (from the Swift perspective) the only visible ones for your subclass.
> The given notes don’t say how to get the modification date, but I got it from the StackOverflow article you mentioned. For the initializer that can take a “URL?” for a decoy file, which modification date are you supposed to use? My code uses “(urlOrNil ?? contentsURL)” to decide. Is that right?
I don’t really know. It’s not clear whether it represents the saved document file or the autosaved document file (the first and second parameters, respectively). I suggest you come back to this later, when you can use the debugger to find out whether it’s updated only at save time or also at autosave time, which will give you the answer.
The other approach to all of this would be to write a shim NSDocument subclass in Obj-C that does the Swift-incompatible super.init calls internally, and presents the desired set of initializers to your Swift sub-sub-class.
_______________________________________________
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