>> >> (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. > > Well, I'm not sure I agree with that. Every initializer in a class should > work correctly. An external caller can initialize a class by calling any of > its init methods, why can't a subclass? > > At the very least, NSWindowController's choice of designated initializer > increases the burden on subclasses.
I’ve thought about the initializer rules quite a bit, convinced at each point that they are too onerous .. and almost always find a reason they aren’t. One that troubled me particularly is why a designated initializer can only call up to another designated initializer and not a convenience one. Surely I thought the convenience one in the superclass must call across as the first thing it does, so a designated initializer in the superclass will thus be called .. where’s the problem. The problem is of course that the designated initializer in the superclass called by the convenience method may have been overridden in the subclass, and that’s the one which would then be called, so you end up calling two different designated initializers for the same class, the one you started from, and the one called by the superclass convenience one you overrode. If you force designated initializers to call only superclass designated initializers, you know you are always going ‘up’. Hence the rule. Hence all the rules. You could add more rules. If you have no non-default properties in your subclass and don’t implement any designated initializers (you wouldn’t have to) then it would be safe for a convenience one to call up to a superclass convenience one. But now we have more rules and as soon as you do add a property you need to initialize and thus have to add an initializer, your class won’t compile any more. I think one of the problems is that if NSWindowController had been originally written in Swift, or in fact if Cocoa had been, then its initializers wouldn’t look quite like they do. That’s just some of the friction between the wild west of Cocoa we’ve all been enjoying for years and the new school mistress of Swift who insists on the rules. It does actually make you do things you should always have done, like subclass initWithCoder:. I hope Xcode will get better at templating out classes or adding stub methods for all designated/required initializers at some point (on request) so that the coding burden reduces. _______________________________________________ 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
