First off, thanks for the answer. Unfortunately either I'm still missing
something, or perhaps my question wasn't precise enough...
> On Aug 10, 2015, at 1:49 PM, Greg Parker <gpar...@apple.com> wrote:
>
> Convenience initializers.
>
> Consider: a superclass that implements a designated initializer and a
> convenience initializer, and your subclass that introduces a new designated
> initializer.
>
> @implementation SomeSuperclass
> -(id) init; // designated initializer
> -(id) convenienceInitializer {
> return [self init];
> }
> @end
...
> or you can implement it to fail at runtime:
>
> @interface YourSubclass
> -(id) init NS_UNAVAILABLE;
> @end
>
> @implementation YourSubclass
> ...
> -(id) init {
> abort(); // or throw or whatever
> }
> @end
>
> Either approach will pacify the compiler.
>
Say that I am taking this approach because it'd be impossible for a
YourSubclass instance to call initWithValue: on itself with an acceptable
"default" value; One is required by the client.
Even though -init is unavailable, it's still actually possible to call
-convenienceInitializer, which will end up calling -[YourSubclass init] and
hitting the abort. That's bad.
We can reason that by definition, convenienceInitializer must call
SomeSuperclass's designated initializer -init. Since we know that -init cannot
possibly setup a YourSubclass instance correctly, then we shouldn't allow
convenienceInitializer to be called either. So now we'd have to mark
convenienceInitializer as NS_UNAVAILABLE in YourSubclass's interface.
By declaring:
@interface YourSubclass
-(id) init NS_UNAVAILABLE;
-(id) convenienceInitializer NS_UNAVAILABLE;
@end
… this now leaves us correctly unable to call [[YourSubclass alloc] init] or
[[YourSubclass alloc] convenienceInitializer].
Which brings me right back to my original question. If neither of those can be
called, then implementations of them in YourSubclass could never be called.
Right? If not, then why does YourSubclass need to provide implementations?
--
Seth Willits
_______________________________________________
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
