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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution