On Feb 14, 2017, at 00:26 , Daryle Walker <dary...@mac.com> wrote:
>
> But I can’t call the “super” versions of those other initializers from within
> my override.
This is the essence of your problem. Your “override” cannot be a convenience
initializer because convenience initializers cannot call “up” to the
superclass, and it cannot be a designated initializer because designated
initializers cannot call convenience initializers. For one solution, see here:
http://stackoverflow.com/questions/38908902/overwriting-nsdocuments-initcontentsofoftype-in-swift
<http://stackoverflow.com/questions/38908902/overwriting-nsdocuments-initcontentsofoftype-in-swift>
Answering the same question in another way, look at the comments for
init(type:) in the NSDocument header file:
> "Initialize a new empty document of a specified type, and return it if
> successful. If not successful, return nil after setting *outError to an
> NSError that encapsulates the reason why the document could not be
> initialized. The default implementation of this method just invokes [self
> init] and [self setFileType:typeName].”
This tells you exactly what the superclass convenience initializer does, and
the fact that it’s in the header file makes the behavior a public API contract.
So, you are allowed to implement your own subclass convenience initializer
(that throws) which does *not* invoke super, but simply does what the super
method is documented to do. (That’s basically the solution given on Stack
Overflow.)
_______________________________________________
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
