Re: Subclassing NSWindowController in Swift
Re: Subclassing NSWindowController in Swift
- Subject: Re: Subclassing NSWindowController in Swift
- From: Quincey Morris <email@hidden>
- Date: Sun, 19 Oct 2014 07:19:03 +0000
On Oct 18, 2014, at 23:46 , Rick Mann <email@hidden> wrote:
>
> The rules on initializers don't make sense to me, in all honesty.
Yes, but that tells us more about you than about Swift — specifically, it tells us that you’re more focused on what would ease your coding task in this one case than on embracing more formal relationships between initializers. Understandable, but not really useful to anyone else, if you’ll forgive my saying so.
> 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.
Yes, but …
(It’s all about the “yes, but”s.)
… calling *up* from a subclass convenience initializer bypasses all of the subclass designated initializers (except in the case that the subclass overrides some or all of the superclass's, which introduces its own semantic ambiguities). That means that the subclass can’t be sure it initialized its own properties, since that’s the purview of designated initializers — at least not without supplementary rules. That in turn destroys the integrity of Swift’s 2-pass initialization process.
The reason that the Swift rules make you uncomfortable is that the Obj-C rules for initializers are comfortably loose, to say the least. It’s always an option to go on using Obj-C, of course.
_______________________________________________
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