<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">I have some use cases that rely on performing setup before calling the super.viewDidLoad().</blockquote></div></div></blockquote><br class=""></div><div class="">In this case you don’t need to write: override(after) func videDidLoad() { … }</div><div class="">Just override will be enough.</div><div class=""><br class=""></div><div class="">From my point of view there is no need to add some constraints to childs. There is some cases where this constraints can help, </div><div class="">but I think they will make the overall system very fragile and inflexible. </div><div class=""><br class=""></div><div class="">override(before), override(after), override(instead) and override affect only one specific function. You cannot constrain child call with it. </div><div class=""><br class=""></div><div class="">Also, simple fix-it should be provided:</div><div class=""><br class=""></div><div class="">1) If no modifiers present and call to super is first call in function --> propose to remove it and add (after) modifier</div><div class="">2) If no modifiers present and call to super is last call in function --> propose to remove it and add (before) modifier</div><div class="">3) If no modifiers present and no call to super in function --> propose to add (instead) modifier</div><div class="">4) If any modifier is present and there is call to super in function body —> propose to remove modifier.</div><div class=""><br class=""></div><div class="">In this case no existing code will be affected of malfunctioning.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 16, 2016, at 4:21 PM, Ross O'Brien <<a href="mailto:narrativium+swift@gmail.com" class="">narrativium+swift@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Jean-Daniel: can you clarify which aspect you're disagreeing with?<div class=""><br class=""></div><div class="">For example: should standard library types prefer the 'override' form which enforces calling super but doesn't enforce when it is called?</div><div class="">Perhaps 'override(before)' should be an indication that, if the overriding method doesn't explicitly declare the super call, then it should be called implicitly at the start of the function?</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Feb 16, 2016 at 2:12 PM, Jean-Daniel Dupas via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
-1 for enforcing the super call place.<br class="">
While we usually call super at the beginning of viewDidLoad for instance, there is absolutely no need to enforce it and it may result in problem when some work have to be done before the super method is executed.<br class="">
<br class="">
I have some use cases that rely on performing setup before calling the super.viewDidLoad().<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
> Le 15 févr. 2016 à 23:06, Alexey Demedetskiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class="">
><br class="">
> Hi<br class="">
><br class="">
> I would like to suggest you to extend your proposal.<br class="">
><br class="">
> In my practice, overriding super functions can have several semantics.<br class="">
> 1) Replace - simple case for abstract classes which implementation do nothing, or throw an exceptions.<br class="">
> 2) After super - things like viewDidLoad and viewWillAppear, setUp etc. All cases where super expect to be called before child code.<br class="">
> 3) Before super - opposite to 2.<br class="">
> 4) Override - no rules about order, but super call must be done.<br class="">
><br class="">
> So code can look like:<br class="">
><br class="">
> override(after) func viewDidLoad() {<br class="">
> // super.viewDidLoad() <— no need to call super at first line.<br class="">
> // child code<br class="">
> }<br class="">
><br class="">
> override(before) func tearDown() {<br class="">
> // clean code<br class="">
> // super… inserted by compiler<br class="">
> }<br class="">
><br class="">
> override(instead) func loadView() {<br class="">
> // super.loadView() <— marked as an error with appropriate fix-up to remove instead modifier<br class="">
> }<br class="">
><br class="">
> override func refillHealthBar() {<br class="">
> // absent call to super will cause an error with fix-up to add (instead) modifier<br class="">
> }<br class="">
><br class="">
> I am not sure about exposing this in a public interface and limit child override options.<br class="">
><br class="">
> But in general - what is your thoughts about this approach to problem that you mention?<br class="">
><br class="">
><br class="">
>> Hi!<br class="">
>><br class="">
>> I would like to suggest to replace the override keyword for functions by something like extend and replace or to add an annotation like @SuppressSuperCall (don’t know a good name for it).<br class="">
>> The reason for this is, that it might happen, that one forgets to call the super’s implementation in an overridden function or if one reads the code it might not be obvious why the super’s implementation is not called:<br class="">
>><br class="">
>> class View {<br class="">
>> func viewDidLoad() {<br class="">
>> // does something<br class="">
>> }<br class="">
>> }<br class="">
>><br class="">
>> class Button: View {<br class="">
>> override func viewDidLoad() {<br class="">
>> super.viewDidLoad() //<— this might be forgotten<br class="">
>> // do something other<br class="">
>> }<br class="">
>> }<br class="">
>><br class="">
>> The compiler will accept if one overrides a superclass’s function but does not call the superclass’s implementation which is often ok. The developer should clearly state that he doesn’t want to call the superclass’s implementation, otherwise the compiler should throw an error.<br class="">
>><br class="">
>> // Example for extending a function<br class="">
>> class Button: View {<br class="">
>> extend func viewDidLoad() {<br class="">
>> super.viewDidLoad()<br class="">
>> // do something<br class="">
>> }<br class="">
>><br class="">
>> extend func viewDidAppear() {<br class="">
>> // do something<br class="">
>> } //<— the compiler should throw an error here.<br class="">
>> }<br class="">
>><br class="">
>> // Example for replacing a function<br class="">
>> class Geometry {<br class="">
>> func volume() ->Double {<br class="">
>> return 0;<br class="">
>> }<br class="">
>> }<br class="">
>><br class="">
>> class Cube: Geometry {<br class="">
>> var length: Double = 0.0<br class="">
>> replace func volume() ->Double {<br class="">
>> let v = length * length * length<br class="">
>> return v<br class="">
>> }<br class="">
>> }<br class="">
>><br class="">
>> Cheers,<br class="">
>> Florian<br class="">
>><br class="">
>><br class="">
>><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>