[swift-evolution] [Idea] Extend "required" to methods other than init()

[Howard Lovatt]

Adding protected access and abstract methods and classes might be easier,
since then you could do:

/* abstract */ class Base {

    /* protected abstract */ func methodToBeOverridden() -> String {
fatalError("Abstract") }

    final func controlsWhenOverrideIsCalled() -> String{

        var s = "In 'super' before override call.\n"

        s += methodToBeOverridden()

        return s + ".\nIn 'super' after override call."

    }

}


class Derived: Base {

    /* protected */ override func methodToBeOverridden() -> String {

        return "In override"

    }

}


let d = Derived()

d.controlsWhenOverrideIsCalled()


Which results in:


In 'super' before override call.

In override.

In 'super' after override call.


Calls to super could then be eliminated from the language!

On 21 January 2016 at 11:53, Jesse Squires <jesse.d.squires at gmail.com>
wrote:

> Thanks Matthew and Howard! A lot of good points there.
>
> There are certainly a few more possible semantics for overrides than I was
> initially thinking. It’s not clear to me if the language should support
> each use case or not. Doing so seems to add unnecessary complexity for
> (potentially) little gain.
>
> I can’t say for sure, but my guess is that the *most common* scenario is:
> "if a method is overridden, it must call super first". This would also make
> automatically synthesizing the call to super simpler, which I think is a
> great idea. Clients then have less of a burden when subclassing.
> However, as noted, non-void returns complicate this. Also, I agree that
> re-purposing `required` could be confusing. I’m open to ideas for an
> alternative keyword.
>
> Again, a lot of good ideas/feedback. I’m actually not sure where this
> leaves us. :) Accounting for all of the possible semantics seems too
> complex and burdensome, though I think our current state is insufficient.
> And perhaps accounting for only the simplest scenario, "if a method is
> overridden, it must call super first", would only further highlight the
> lack of ability to express the other possible semantics.
>
> ¯\_(ツ)_/¯  I’d love to hear if anyone else has ideas or shares these
> concerns!
>
> Jesse
>
>
> > On Jan 18, 2016, at 11:34 AM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >>>
> >>> Are there other languages worth investigating which have the requires
> super first/last semantics you note?
> >>
> >> I don’t know of any languages that support this.  It is not the most
> common semantic, but when it occurs it seems important enough that it would
> be better if it could be specified in the language itself and enforced
> rather than left to documentation.
> >
> > BETA has this ability, but it worked rather differently than modern OO
> languages (which work more like its predecessor Simula). In BETA you can
> only ever call the top most method, it can then optionally call the
> immediately overriding method. The syntax BETA uses is `inner(<args>)`.
> Probably easier with examples (in BETArised Swift):
> >
> >    class Base {
> >        func finalM() { print("finalM") }
> >        func mustOverrideM() {
> >            print("beforeInner")
> >            inner()
> >            print("afterInner")
> >        }
> >    }
> >
> >    class Derived: Base {
> >        func mustOverrideM() {
> >            print("inInner")
> >        }
> >    }
> >
> > Methods `finalM` and `Derived.mustOverrideM` are automatically final
> because they do not call inner.
> >
> > You can't make an instance of `Base` because method `Base.mustOverrideM`
> needs to be overridden, i.e. `Base` is automatically abstract.
> >
> > If you:
> >
> >    let d = Derived()
> >    d.mustBeOverriddenM()
> >
> > Then it prints:
> >
> >    beforeInner
> >    inInner
> >    afterInner
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160121/79568dd3/attachment.html>