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

[Nate Birkholz]

I feel like leaving whether and when to call super up to the programmer is
a more general solution. In my current codebase, calling super on an
inherited method is what i *don't* want, instead overriding the whole
method on every child.

On Wed, Jan 20, 2016 at 4:53 PM, Jesse Squires via swift-evolution <
swift-evolution at swift.org> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Nate Birkholz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160120/5fbccee7/attachment.html>