[swift-evolution] Add code to super methods.

[Dave Abrahams]

on Tue Nov 29 2016, Goffredo Marocchi <panajev-AT-gmail.com> wrote:

>> On 29 Nov 2016, at 17:33, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 29 Nov 2016, at 16:55, Aron Lindberg via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>
>>> While I agree with most of your points Dave, I think forgetting to
>>> call super is very much a (hard to debug) real world problem today.
>> 
>> I don’t. I’ve done it a few times but I don’t remember ever having a hard time debugging it.
>> 
>> 
>>> Especially new developers seems unsure or likely to forget to call super when it is required.
>>> 
>>> I think my point is this; When you subclass code you have not
>>> written yourself you have no idea if the class you are subclassing
>>> is "poorly designed" and you should call super somewhere in your
>>> documentation. You can make assumptions, read the documentation or
>>> use trial and error, but there is no way to be certain unless the
>>> documentation is specific about it.
>> 
>> There’s a fine line between being a safe language and being as
>> nannying language and I think proposals about “must call super” and
>> “must not call super” overstep the line - that’s just my opinion, of
>> course.
>
> Final / closed by default was in and calling super oversteps :)?
>
> Anyways to go back to a more serious point, like Tino said earlier,
> this is for Dave's comment, sometimes I get the feeling object
> oriented programming and inheritance are supported but unwelcome a
> bit. 

Let me be clear: that is my very personal prejudice, which I admit to
(and then exaggerate a bit for comic effect).  Swift has every intention
of being great for, and welcoming, OOP.

> We should not discourage a feature we support, but just make the
> alternatives so so good that people will not want to use anything but
> them (unless they really need to use the older practice of course).
>
> I think this is part of being opinionated, but one of the two aspects:
> do you reward good behaviour over punishing bad one or do you try to
> make people do something better by rendering the alternative more
> limited/less appealing?
>
> (In less serious tone) C'mon Crusty, you refused to move to classes
> with C in the early 80's, staying strong and steady worked, you stuck
> with structs and function pointers, you have won with Swift... there's
> no need to spike the ball :P.

:-).  Look, I'm not spiking the ball.  I'm saying, the best practice is
to create designs where you don't have to (and even, if supported by the
language, can't) call super.  Anyone who doesn't believe me should
search the web for questions about when and whether to call super in
viewWillAppear.  APIs that leave programmers with persistent open
questions that don't have clear answers should be improved.

If lots of designs fail to follow that idiom, well, we should certainly
help people to be effective with those designs in spite of their
deficiencies.  But we absolutely should *not* punish the best practice
by making the compiler spew warnings when it is followed.

-- 
-Dave