[swift-evolution] Replace the override keyword by 'extend' and 'replace' or add an annotation like @SuppressSuperCall

[Vanderlei Martinelli]

My vote is for a simple `require(override)` or `require(super)` on the
super-class. The user should be free to choose where to call super if
needed where she/he wants.

Other thing that I think is related is to declare a func abstract
(something like `require(override)` but without body implementation).


-Van

On Tue, Feb 16, 2016 at 4:12 PM, Shawn Erickson via swift-evolution <
swift-evolution at swift.org> wrote:

> Not that I disagree with having a superclass overly dictate what a
> subclass can do... it can quickly become a double edges sword however it
> can be powerful for complex class designs especially if they focus on
> extension via subclassing.
>
> It should be noted it isn't always possible to leverage the super class
> calling a final method as a point of enforcement. If the interface is
> public then any code could call an overridden function without the ability
> for the super class to enforce desired requirements. (yeah you could likely
> achieve this by having the overridables have non-public access)
>
> Anyway some more thinking out loud...
>
> sub-class:
>
> override -> implies that the subclass intends to override a function of
> its super class chain, if no such function is found up the chain at compile
> time then a compiler error can be omitted to help catch missed function
> signature changes that affect a sub-class (or fat fingering of a function
> name), if absent and an override is taking place the compiler could also
> flag unexpected override (e.g. function signature collision).
>
> override with no qualifier is assumed to imply the overriding code should
> at some point call up to the supers implementation, if that isn't found the
> compiler should provide a fixup to either add the (instead) qualifier to
> make it clear you want to replace the supers implementation or force you to
> add a call to super
>
> override(before) & override(after) could exist to help catch errors and/or
> generate code as needed (super call not needed in the overriding)
>
> override func foo() {...}
> override(instead|before|after) func bar() {...}
>
> super-class:
>
> require -> implies some requirement for those subclassing the function
>
> require(override) -> implies that a subclass must override and that the
> class stating this requirement should be considered abstract
>
> require(super) -> states that any override must call supers implementation
> at some point in its body, override(instead) wouldn't be allowed, if the
> requirement is not specified the subclass is free to call or not call the
> supers implementation
>
> require(superBefore) -> states that it is expected that a subclass calls
> super before doing things in its override, if the subclass doesn't doesn't
> honor this requirement the compiler will help to enforce it however a
> subclass could state it is explicitly ignoring that requirement by say
> something like override(ignoreBefore), override(instead) wouldn't be
> allowed, consider this an escape hatch for subclasses,
>
> require(superAfter) -> same as above but after the override body
>
> Note something like require(override, superXxx) is valid allowing for a
> base class to provide some amount of implementation while still being
> considered an abstract class.
>
> final func baz() {...}
> require(override) func foo() {}
> require(override, super|superBefore|superAfter) func bar() {...}
>
> Note I have not convinced myself of the true need for something like this
> but I see being a potential benefit for class authors.
>
> -Shawn
>
>
> On Tue, Feb 16, 2016 at 6:51 AM Sean Heber via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Agreed - attempting to enforce the ordering is too fiddly and
>> complicated, IMO. If the superclass must ensure a specific order, then it
>> should do so itself by first calling a final function that then calls the
>> overridable function at the right time.
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160216/5169f663/attachment.html>