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@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 superoverride(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 abstractrequire(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 implementationrequire(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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution