• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Why is overriding unavailable designated initializer of super required?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why is overriding unavailable designated initializer of super required?


  • Subject: Re: Why is overriding unavailable designated initializer of super required?
  • From: Greg Parker <email@hidden>
  • Date: Mon, 10 Aug 2015 16:29:43 -0700

> On Aug 10, 2015, at 3:50 PM, Seth Willits <email@hidden> wrote:
>
> 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?

Writing a halting cover for the superclass's designated initializers is a defensive measure. If you miss one of the convenience initializers then getting an immediate crash with a crash log pointing to the initializer is much better than quietly calling the wrong initializers and mysteriously crashing somewhere else later.

The compiler's enforcement is for designated initializers because they should be a bottleneck that the compiler can see. Enforcing covers of every superclass convenience initializer would be difficult because it's likely that the compiler can't see them all when compiling your subclass, and would be cumbersome because there are often many more convenience initializers.


--
Greg Parker     email@hidden     Runtime Wrangler



_______________________________________________

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


  • Follow-Ups:
    • Re: Why is overriding unavailable designated initializer of super required?
      • From: Seth Willits <email@hidden>
References: 
 >Why is overriding unavailable designated initializer of super required? (From: Seth Willits <email@hidden>)
 >Re: Why is overriding unavailable designated initializer of super required? (From: Greg Parker <email@hidden>)
 >Re: Why is overriding unavailable designated initializer of super required? (From: Seth Willits <email@hidden>)

  • Prev by Date: Re: ARC and Manual Memory Management
  • Next by Date: Re: Why is overriding unavailable designated initializer of super required?
  • Previous by thread: Re: Why is overriding unavailable designated initializer of super required?
  • Next by thread: Re: Why is overriding unavailable designated initializer of super required?
  • Index(es):
    • Date
    • Thread