[swift-evolution] Add code to super methods.
Jay Abbott
jay at abbott.me.uk
Wed Nov 16 17:16:01 CST 2016
Hi Mustafa,
This is an interesting idea. The wording needs to be clear that it is not
adding/injecting any code into the super-class. I would call it something
like a cascading or chained method - there may be a better name and
probably already is, because deinit already behaves in a similar way - the
compiler enforces that you don’t call it directly and it cascades the calls
up the super-class chain skipping ones where deinit is not implemented.
I think this should be something declared in the super-class though, not
something that a sub-class would use for the convenience of omitting the
super call. That is, the super-class demands of the compiler that its
implementation is always called when this method is called on any sub-class
(and this enforcement is inherited so all implementations in each sub-class
are guaranteed to be called).
A class could declare a method to be chained (or whatever) and the compiler
would ensure that overrides definitely call the super method, or
automatically inject it if they don’t. This would give sub-classes the
flexibility to call it anywhere they like (before or after or in the middle
of their implementation) and they could also modify the parameters passed
to it. There could also be head/tail variations that enforce super is
called at the beginning or end of sub-class implementations, rather than
anywhere.
This is also similar to how the compiler enforces the init calls are made
up the class hierarchy, but with init each sub-class might have different
parameters for their initialisers. However with a method, if you introduce
different/additional parameters it is now a new method, and no longer an
override. Would it be desirable to enforce a chain in this case - when a
sub-class wants to change the signature part way down the chain such that
all its sub-classes cannot override the original method but must use a
different one instead? This seems related but probably needs a lot more
thought and a diverse set of examples to guide the design.
On Wed, 16 Nov 2016 at 22:30 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161116/16bb50af/attachment.html>
More information about the swift-evolution
mailing list