[swift-evolution] [Discussion] Enforcing Calling Super

[Kyle Sherman]

I'm convinced that we shouldn't add the begin/end functionality to this proposal. So, I will remove that from the proposal, add in reference to the NS_REQUIRES_SUPER macro, and post the final proposal for review. 

Sent from my iPhone

On Feb 29, 2016, at 8:01 AM, Jeremy Pereira <jeremy.j.pereira at googlemail.com> wrote:


> On 25 Feb 2016, at 23:02, Haravikk <swift-evolution at haravikk.me> wrote:
> 
> 
>> On 25 Feb 2016, at 15:47, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> In particular, it is absurd to enforce having the call to super as the first or last line of the method. That would stop me doing things like this:
>> 
>>   override func viewDidLoad()
>>   {
>>       print(“About to run super.viewDidLoad()”)
>>       super.viewDidLoad()
>>       print(“Finished super.viewDidLoad()”)
>>   }
>> 
>> Then there’s the perfectly reasonable case like this:
>> 
>>   override func viewDidLoad()
>>   {
>>       functionThatCallsSuperViewDidLoad()
>>   }
>> 
>> Why shouldn’t I be allowed to do that?
> 
> Because the parent class told you not to?

And what right does the parent class have to tell me not to?


> I’ve said repeatedly on the subject now however that before/after constraints aren’t something that you should expect to see commonly,

Before and after constraints should never be seen. How can the designer of the superclass possibly know what code is safe in front of the call to super and what isn’t?


> as they’re something that developers should only set if they are absolutely certain that they will be required. The way I see it they will be most commonly used in two particular cases:
> 
>    • Partial Implementation: For an abstract-style class, a provided partial implementation might only handle the preliminary setup or final handling of values, in which case it must be called first or last in order for an implementation to be completing it correctly.

And what if I want to put a log message in front of the call?

>    • Undefined State: If the parent class shares values and methods for sub-classes to use, but cannot guarantee a consistent state if they are called without the super method. Again this is really more likely to happen in types that are specifically intended for extension where order may be important, rather than a complete type that you just happen to decide to extend.

I think I would design my superclass better so that this situation doesn’t arise.