Can a non-designated initializer call a super's designated initializer?

Question

Can the following be done?

1) a non-designated initializer call the super class's designated initializer
2) a class's designated initializer call the super class's non-designated initializer?

Or must the flow be:

a) a designated initializer must call superclass's designated initializer
b) a non-designated initializer must call own class's designated initializer

What if (1) or (2) above is violated, what could happen? (or, if we must always follow (a) and (b), what is the reason behind it?)

Answer 1

Can the following be done?

1) a non-designated initializer call the super class's designated initializer

It actually must be done since there is no way you as a subclass implementor can know what code is inside the superclass designated initializer and implement it yourself without posessing the code. You have no other reasonable way to init the super class.

Regardless of whether you are a subclass or an external client you must call the designated initializer. The docs quoted above are incorrect.

2) a class's designated initializer call the super class's non-designated initializer?

If non-designated initializers are provided by the super and implemented to call the designated initializer there is absolutely no problem in calling any initializer on the parent.

The previous answer would make it seem that you have to basically implement all super class constructors in your own code without having the code. Wrong. Thats why super class initializers exist, so that you can extend them safely without having the code.

Answer 2

• 1: No.
• 2: Yes.
• a: Arguable.
• b: Yes.

The point of a designated initializer is that it's the initializer that knows how to properly set up the object at hand. All the other initializers in the class should call the designated initializer; if they don't, the object may not be properly initialized.

Apple's Cocoa documentation discusses how to handle multiple initializers, and it includes the following:

The initializer of a class that takes the full complement of initialization parameters is usually the designated initializer. The designated initializer of a subclass must invoke the designated initializer of its superclass by sending a message to super.

That's a little ambiguous -- it sounds like the designated initializer of a subclass must call the designated initializer of its superclass. But I don't think that's the real intent. The real point here is that it's the designated initializer's responsibility to make sure that the superclass is properly initialized by sending a message to super. If you happen to do that by calling one of super's non-designated initializers, that should be fine provided that that initializer eventually causes the designated initializer to be called. For that reason, I don't believe that (2) is a problem.

Reading further we have:

The convenience (or secondary) initializers—which can include init—do not call super.

So what they're saying here is that an important difference between the designated initializer and any other initializers is that the designated initializer is the only one that sends an initialization message to super.

Getting back to (1), if you have a "non-designated" initializer that calls [super init], that's not really a non-designated initializer. Your method is taking on the responsibility of a designated initializer by sending an initialization message to super. That's not necessarily a problem -- note that UIView has two designated initializers -- but it breaks the usual convention, so you should have a pretty good reason for doing it.

Answer 3

As creating a designated initializer is not formal, it is up to you to violate the rules.

A common practice for a class with multiple initializers is to make the one which accepts the most arguments the designated initializer and let all the other initializers call it. Only the designated initializer gets to call the designated initializer of the superclass, which follows the same rules.

If others subclass your class and call the designated initializer, they are sure all instance variables are correctly initialized. If your class does not follow these common practices, you could create a messy class to begin with for yourself, but make it even harder to use for others.