<div dir="ltr">The addition of before and after are just icing on the cake as they say (I see benefit but am not sure about them being worth it). I agree the core benefit would come from being able to state "require override" as a base class with or without providing an implementation. The only hole I see in that is how to help subclassers detected missed calls to super (subclass override(instead) helps deal with that well enough). I could see require (override) and require (override,super) as base class if the author strongly feels a subclass needs to involve the supers implementation... of course then you get back to the edge case of before and after.<div><br></div><div>So at it core I support...</div><div><br></div><div>For base classes require(override) with or without an implementation, without implies abstract, with implies a subclass should likely call the base implementation in its override</div><div><br></div><div><div>For subclasses override to detect override attempts or on omission flag unexpected overrides, override(instead) to state it is ok that supers implementation isn't called in the override (assumed to be desired unless instead is stated).</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 16, 2016 at 11:24 AM Vanderlei Martinelli <<a href="mailto:vmartinelli@alecrim.com">vmartinelli@alecrim.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Other thing that I think is related is to declare a func abstract (something like `require(override)` but without body implementation).</div><div><div><br></div><div><br></div><div>-Van</div></div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 16, 2016 at 4:12 PM, Shawn Erickson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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)</div><div><br></div><div>Anyway some more thinking out loud...</div><div><br></div><div>sub-class:</div><div><br></div><div>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).</div><div><br></div><div>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</div><div><br></div><div>override(before) & override(after) could exist to help catch errors and/or generate code as needed (super call not needed in the overriding)</div><div><br></div><div>override func foo() {...}</div><div>override(instead|before|after) func bar() {...} </div><div><br></div><div>super-class:</div><div><br></div><div>require -> implies some requirement for those subclassing the function</div><div><br></div><div>require(override) -> implies that a subclass must override and that the class stating this requirement should be considered abstract</div><div><br></div><div>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<br></div><div><br></div><div>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,</div><div><br></div><div>require(superAfter) -> same as above but after the override body</div><div><br></div><div>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.</div><div><br></div><div>final func baz() {...}</div><div>require(override) func foo() {}<br></div><div>require(override, super|superBefore|superAfter) func bar() {...}</div><div><br></div><div>Note I have not convinced myself of the true need for something like this but I see being a potential benefit for class authors.</div><div><br></div><div>-Shawn</div><span><div><br><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 16, 2016 at 6:51 AM Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
</blockquote></div></div></div></span></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div></div></blockquote></div>