On Oct 19, 2014, at 00:24 , Rick Mann <rm...@latencyzero.com> wrote: > > Well, I'm not sure I agree with that. Every initializer in a class should > work correctly.
If, hypothetically, a subclass was allowed to call any initializer in the superclass, then the result would be an object that was fully (“correctly”) initialized in terms of the superclass, but that doesn’t mean it’s fully initialized in terms of the subclass. This distinction just doesn’t apply to Obj-C. The difference is that in Obj-C you never initialize any instance storage *before* calling “up” (aside from the automatic zeroing of it all). In Swift, you may. > An external caller can initialize a class by calling any of its init methods, > why can't a subclass? In Swift, an external caller cannot initialize a class by calling one of its superclass initializers — formally. In practice, there are two cases: 1. The subclass declares *no* designated initializers, in which case it inherits all of the superclass designated initializers. In this case, external callers still aren’t really calling a superclass initializer, just something that looks like it. 2. The subclass declares its own designated initializers (either overrides or not). In this case, external callers can only call initializers that are declared in the subclass, and nothing is inherited externally. Case #2 formalizes something that is currently unsafe in Obj-C. Case #1 allows many existing Obj-C class patterns to be safely usable in Swift without additional coding. There is no case #3 that partially overlaps #1 and #2, since it would generally be unsafe. _______________________________________________ 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
