[swift-evolution] Add code to super methods.

Javier Soto javier.api at gmail.com
Wed Nov 16 16:45:56 CST 2016


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 <
swift-evolution at swift.org> 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 <sean at fifthace.com> 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 <
swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161116/b266c892/attachment.html>


More information about the swift-evolution mailing list