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

[Vanderlei Martinelli]

+1 to @super :-)

On Mon, Feb 15, 2016 at 8:52 PM, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

> This is an interesting idea, and fits well with the theme of preventing
> mistakes in Swift, but I think that the proposed solution isn’t flexible
> enough, as there are cases for inheritance patterns where extending doesn’t
> actually make sense, so having to specify an exception every time could
> quickly become annoying.
>
> I think the better solution is to instead allow super-classes to specify
> whether or not their method must be called when overridden/extended. For
> example:
>
> class View {
> @super(required) func viewDidLoad() { … }
> }
>
> class Button : View {
> override func viewDidLoad() { … }
> }
>
> class Widget : View {
> override func viewDidLoad() {
> super.viewDidLoad()
> …
> }
> }
>
> In this extension of your example Button will cause an error because it
> overrides viewDidLoad() but fails to call the parent’s method as required
> by the @super attribute. However, Widget compiles successfully because it
> follows the requirement.
>
> So the options for @super would be:
>
>
>    - *required: *child-class must call parent implementation of this
>    method.
>    - *optional:* default behaviour, child can choose whether to call the
>    parent’s method.
>    - *denied:* child may not call parent’s method (useful if it makes
>    assumptions that a child-class may not follow), but can still
>    extend/override.
>
>
> I think this would be a more flexible solution to the problem, and put the
> decision in the hands of those writing classes designed for inheritance.
> I’m not 100% sure of whether to rename override to extend, I like extend
> better personally, but it probably doesn’t matter overall.
>
> On 15 Feb 2016, at 20:57, Florian Liefers via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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
>
>
>
> _______________________________________________
> 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/c01ceb44/attachment.html>