<div style="white-space:pre-wrap">This has been discussed a few times already. As far as I can remember, the major takeaways were:<br><br>- Often APIs want you to call super either before or after your implementation, so we would need syntax for that too<br>- Protocols and composition are often a much better way to model this, as opposed to relying on things like the method call ordering.</div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Nov 16, 2016 at 2:39 PM Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All that said, there is a slight flaw here which is - what happens if you want to alter the input to super’s method in your override? That might be a deal-breaker.<br class="gmail_msg">
<br class="gmail_msg">
l8r<br class="gmail_msg">
Sean<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> On Nov 16, 2016, at 4:37 PM, Sean Heber <<a href="mailto:sean@fifthace.com" class="gmail_msg" target="_blank">sean@fifthace.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> That could be kind of neat - perhaps a syntax more like this so that there isn’t another bare keyword:<br class="gmail_msg">
><br class="gmail_msg">
> override(after) func viewDidLoad() {<br class="gmail_msg">
> }<br class="gmail_msg">
><br class="gmail_msg">
> and:<br class="gmail_msg">
><br class="gmail_msg">
> override(before) func viewDidLoad() {<br class="gmail_msg">
> }<br class="gmail_msg">
><br class="gmail_msg">
> Which would allow you to specify where your code happens - either before or after the superclass method, essentially. Leaving out before/after would still behave as expected and you’d have to call super yourself (or not):<br class="gmail_msg">
><br class="gmail_msg">
> override func viewDidLoad() {<br class="gmail_msg">
> // stuff<br class="gmail_msg">
> super.viewDidLoad()<br class="gmail_msg">
> // more stuff<br class="gmail_msg">
> }<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> A potentially neat thing about this is that you could possibly then impose restrictions on subclasses like so:<br class="gmail_msg">
><br class="gmail_msg">
> final(before) func viewDidLoad() {}<br class="gmail_msg">
><br class="gmail_msg">
> Which could mean that the “before” slot is “final” - therefore you cannot do either of these:<br class="gmail_msg">
><br class="gmail_msg">
> override func viewDidLoad() {}<br class="gmail_msg">
> override(before) func viewDidLoad() {}<br class="gmail_msg">
><br class="gmail_msg">
> l8r<br class="gmail_msg">
> Sean<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
>> On Nov 16, 2016, at 4:30 PM, Mustafa Sabur via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> Hallo,<br class="gmail_msg">
>><br class="gmail_msg">
>> I have a very simple suggestion. And I’m not very sure then it haven’t been discussed already, so I’m sorry if that is the case.<br class="gmail_msg">
>> I would like to see the ability to just add code to base methods instead of overriding it and calling supers method. So basically an extension for methods.<br class="gmail_msg">
>><br class="gmail_msg">
>> Example:<br class="gmail_msg">
>><br class="gmail_msg">
>> Now:<br class="gmail_msg">
>> override func viewDidLoad() {<br class="gmail_msg">
>> super.viewDidLoad()<br class="gmail_msg">
>> // Your code<br class="gmail_msg">
>> }<br class="gmail_msg">
>><br class="gmail_msg">
>> Suggestion:<br class="gmail_msg">
>> addinto func viewDidLoad() {<br class="gmail_msg">
>> // Your code<br class="gmail_msg">
>> }<br class="gmail_msg">
>><br class="gmail_msg">
>> My reasons:<br class="gmail_msg">
>> 1. Its very verbose about your intentions, which fits into Swift style. The thing you actually want is not overriding but appending.<br class="gmail_msg">
>> 2. You cannot make the mistake of forgetting to call the supers method.<br class="gmail_msg">
>> 3. It open ways to introducing ‘semi-final’ methods, which cannot be override but you still can append to it.<br class="gmail_msg">
>> This to make sure your API implementation will always be executed . I’m thinking about a keyword like extendable to specify that you can only add to it.<br class="gmail_msg">
>> 4. Less code.<br class="gmail_msg">
>><br class="gmail_msg">
>> I can’t think of any cons... Thought I can imagine that the benefits are quite small and maybe not worth the effort.<br class="gmail_msg">
>> I would like to read some thoughts about this. Thank you!<br class="gmail_msg">
>><br class="gmail_msg">
>> Kind regards,<br class="gmail_msg">
>> Mustafa Sabur<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-evolution mailing list<br class="gmail_msg">
>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">Javier Soto</div></div>