[swift-evolution] Replace the override keyword by 'extend' and 'replace' or add an annotation like @SuppressSuperCall

[Shawn Erickson]

+1 for what you outlined Alexey. I think maintaining the use of override as
the keyword is the most understandable in the context and also is
terminology usually used in various object languages. I like adding the
optional qualifiers to allow (1) better diagnostics by the compiler, (2)
clearer code, and (3) the opportunity for compiler generating the need
coded (in a few of the situations).

Can something like this be used in the super classes interface definition
to clarify expectations of a subclass?

On Mon, Feb 15, 2016 at 2:07 PM Alexey Demedetskiy via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi
>
> I would like to suggest you to extend your proposal.
>
> In my practice, overriding super functions can have several semantics.
> 1) Replace - simple case for abstract classes which implementation do
> nothing, or throw an exceptions.
> 2) After super - things like viewDidLoad and viewWillAppear, setUp etc.
> All cases where super expect to be called before child code.
> 3) Before super - opposite to 2.
> 4) Override - no rules about order, but super call must be done.
>
> So code can look like:
>
> override(after) func viewDidLoad() {
>     // super.viewDidLoad() <— no need to call super at first line.
>     // child code
> }
>
> override(before) func tearDown() {
>     // clean code
>     // super… inserted by compiler
> }
>
> override(instead) func loadView() {
>     // super.loadView() <— marked as an error with appropriate fix-up to
> remove instead modifier
> }
>
> override func refillHealthBar() {
>    // absent call to super will cause an error with fix-up to add
> (instead) modifier
> }
>
> I am not sure about exposing this in a public interface and limit child
> override options.
>
> But in general - what is your thoughts about this approach to problem that
> you mention?
>
>
> > Hi!
> >
> > I would like to suggest to replace the override keyword for functions by
> something like extend and replace or to add an annotation like
> @SuppressSuperCall (don’t know a good name for it).
> > The reason for this is, that it might happen, that one forgets to call
> the super’s implementation in an overridden function or if one reads the
> code it might not be obvious why the super’s implementation is not called:
> >
> > class View {
> > func viewDidLoad() {
> > // does something
> > }
> > }
> >
> > class Button: View {
> > override func viewDidLoad() {
> > super.viewDidLoad() //<— this might be forgotten
> > // do something other
> > }
> > }
> >
> > The compiler will accept if one overrides a superclass’s function but
> does not call the superclass’s implementation which is often ok. The
> developer should clearly state that he doesn’t want to call the
> superclass’s implementation, otherwise the compiler should throw an error.
> >
> > // Example for extending a function
> > class Button: View {
> > extend func viewDidLoad() {
> > super.viewDidLoad()
> > // do something
> > }
> >
> > extend func viewDidAppear() {
> > // do something
> > } //<— the compiler should throw an error here.
> > }
> >
> > // Example for replacing a function
> > class Geometry {
> > func volume() ->Double {
> > return 0;
> > }
> > }
> >
> > class Cube: Geometry {
> > var length: Double = 0.0
> > replace func volume() ->Double {
> > let v = length * length * length
> > return v
> > }
> > }
> >
> > Cheers,
> > Florian
> >
> >
> >
> _______________________________________________
> 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/20160215/e1d7d9ee/attachment.html>