A lot of the time Cocoa documentation says that you must override a method,
or must not, and if you do, whether to to it in the beginning, the end, or
at some point. This proposal would make it enforceable by the compiler.
With the right defaults, this could function exactly as what we have today
but give additional ways for the compiler to enforce and automate the
implementor's intent instead of relying on the documentation.
···
On Tue, Feb 16, 2016 at 10:00 AM Alexey Demedetskiy via swift-evolution < swift-evolution@swift.org> wrote:
I understand what you are talking about.
But point is not to limit available behaviors, but to give some hints to
compiler and protect programmer from errors.From my point of view, there is no need to specify order in super class.
But this can be helpful in child classes. I mean, that programmer will
define the semantic of overriding, and not the semantic of inheritance.> I disagree with the introduction of a method to specify if super must be
call first or last. Defining that super must be call is fine, but I don’t
see why the operation order should be enforced.
>
> If the super class declares a method overridable but require that some
code must be perform first, it can simply execute that code before calling
the overridable method instead of putting it in the super class definition
then force the subclass to call super first.
>
> Moreover, I’m not fond of declaring that requirement in the overriding
classes. That is the superclass that should define if a super
implementation is required, not the children classes.
>
>
> > Le 16 févr. 2016 à 15:21, Ross O'Brien via swift-evolution< > swift-evolution@swift.org(mailto:swift-evolution@swift.org)>a écrit :
> > Jean-Daniel: can you clarify which aspect you're disagreeing with?
> >
> > For example: should standard library types prefer the 'override' form
which enforces calling super but doesn't enforce when it is called?
> > Perhaps 'override(before)' should be an indication that, if the
overriding method doesn't explicitly declare the super call, then it should
be called implicitly at the start of the function?
> >
> >
> > On Tue, Feb 16, 2016 at 2:12 PM, Jean-Daniel Dupas via swift-evolution< > swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > >
> > > -1 for enforcing the super call place.
> > > While we usually call super at the beginning of viewDidLoad for
instance, there is absolutely no need to enforce it and it may result in
problem when some work have to be done before the super method is executed.
> > >
> > > I have some use cases that rely on performing setup before calling
the super.viewDidLoad().
> > >
> > > >Le 15 févr. 2016 à 23:06, Alexey Demedetskiy via swift-evolution< > swift-evolution@swift.org(mailto:swift-evolution@swift.org)>a écrit :
> > > >
> > > >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@swift.org(mailto:swift-evolution@swift.org)
> > > >https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto: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