[swift-evolution] Idea: using 'super()' as syntactic sugar for 'super.overriddenmethod(...)'?

[William Shipley via swift-evolution]

In cases like this:

    override func loadView() {
        super.loadView()
        view.addSubview(segmentedControl)
        segmentedControl.translatesAutoresizingMaskIntoConstraints = false
        segmentedControl.centerXAnchor.constraint(equalTo: 
view.centerXAnchor).isActive = true
    }

or

    override open func prepare(for segue: NSStoryboardSegue, sender: Any?) {
        if let destinationController = segue.destinationController as? 
ScaleViewController {
            scaleViewController = destinationController
            destinationController.scalable = self // weak back-link
        }
        super.prepare(for: segue, sender: sender)
    }

We obviously need the ability to manually place the call to ‘super’ in our 
overridden methods, so we can’t just have the compiler always automatically 
call super (like it does with dealloc).

But only occasionally do we need to pass in different parameters to the 
superclass method than were passed into us, and it’d be nice to ⑴ not have to 
do all the extra typing / reading in the common case, ⑵ makes it clear at a 
glance we’re calling the _same_ method on our superclass, not accidentally 
calling a different one, and ⑶ make it especially noticeable when we ARE 
changing the parameters around to our call to super by having that be the only 
version where you need to specify them.

So, for instance, the above two methods would turn into:

    override func loadView() {
        super()
        view.addSubview(segmentedControl)
        segmentedControl.translatesAutoresizingMaskIntoConstraints = false
        segmentedControl.centerXAnchor.constraint(equalTo: 
view.centerXAnchor).isActive = true
    }

or

    override open func prepare(for segue: NSStoryboardSegue, sender: Any?) {
        if let destinationController = segue.destinationController as? 
ScaleViewController {
            scaleViewController = destinationController
            destinationController.scalable = self // weak back-link
        }
        super()
    }

But this contrived example would stay the same:

    override public func mouseDown(with event: NSEvent) {
        let someOtherEvent = …
        super.mouseDown(with: someOtherEvent)
    }

Note that I just made up a contrived example here because I couldn’t find a 
single real-world case in my 33,098 lines of Swift code where I call 
super.blah(…) with different parameters than the ones that were passed in, 
which I think also points to why this syntactic sugar is sweet and low-cal. 
(The only time I saw super being called with different parameters was in init() 
methods, where I was calling a different initializer.)

—

Another version would be to use a new word instead of “super()”, which doesn’t 
overload the noun-ish-ness of ‘super’:

        overridden()
or
        superfunc()


It’s possible that the empty parenthesis in “super()” would confuse readers 
into thinking some other version of their function is being called (that has no 
parameters), so it’s worth considering if something like “overridden” by itself 
(no ()) would be better. I think if this is a worry I’d prefer to use three 
dots to indicate more stuff is going on here, to match with our documentation:

        super(...)
or
        overridden(...)

An orthogonal idea is for the contrived example would be to allow new 
parameters to be passed in directly without typing the function name again:

        super(with: someOtherEvent)
or
        overridden(with: someOtherEvent)


-Wil



_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution