This has been discussed a few times already. As far as I can remember, the major takeaways were:
- Often APIs want you to call super either before or after your implementation, so we would need syntax for that too - Protocols and composition are often a much better way to model this, as opposed to relying on things like the method call ordering. On Wed, Nov 16, 2016 at 2:39 PM Sean Heber via swift-evolution < [email protected]> wrote: 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. l8r Sean > On Nov 16, 2016, at 4:37 PM, Sean Heber <[email protected]> wrote: > > That could be kind of neat - perhaps a syntax more like this so that there isn’t another bare keyword: > > override(after) func viewDidLoad() { > } > > and: > > override(before) func viewDidLoad() { > } > > 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): > > override func viewDidLoad() { > // stuff > super.viewDidLoad() > // more stuff > } > > > A potentially neat thing about this is that you could possibly then impose restrictions on subclasses like so: > > final(before) func viewDidLoad() {} > > Which could mean that the “before” slot is “final” - therefore you cannot do either of these: > > override func viewDidLoad() {} > override(before) func viewDidLoad() {} > > l8r > Sean > > > >> On Nov 16, 2016, at 4:30 PM, Mustafa Sabur via swift-evolution < [email protected]> wrote: >> >> Hallo, >> >> 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. >> 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. >> >> Example: >> >> Now: >> override func viewDidLoad() { >> super.viewDidLoad() >> // Your code >> } >> >> Suggestion: >> addinto func viewDidLoad() { >> // Your code >> } >> >> My reasons: >> 1. Its very verbose about your intentions, which fits into Swift style. The thing you actually want is not overriding but appending. >> 2. You cannot make the mistake of forgetting to call the supers method. >> 3. It open ways to introducing ‘semi-final’ methods, which cannot be override but you still can append to it. >> 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. >> 4. Less code. >> >> I can’t think of any cons... Thought I can imagine that the benefits are quite small and maybe not worth the effort. >> I would like to read some thoughts about this. Thank you! >> >> Kind regards, >> Mustafa Sabur >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution -- Javier Soto
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
