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

[Haravikk]

> On 17 Feb 2016, at 08:06, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I’m sorry, I don’t believe this. How can the implementor of the superclass possibly know whether the arbitrary code that the implementor of a subclass can write should go before, after or around the call to the super implementation? It’s nonsense.

The before and after clauses probably wouldn’t be the most commonly used except in cases where the developer is very sure that they are needed. I think they’d be used more by abstract classes than regular ones, where a partial implementation needs to be completed in a particular way, required and optional would be the most commonly used I think.

> They couldn’t call out to a private method to call the super implementation.

What do you hope to gain by doing so? If the parent method requires that it is called then it has to called in all paths the sub-class implementation can take. You can still outsource work to a private method, you can even still make a decision based on what the private method’s results are, so long as you call the super method in every case.

> They couldn’t put it inside a loop or control structure unless the compiler can definitely prove that the code path is executed.

Why would you want to potentially call the super-method zero or many times when your child method is only called once? I’d also say that this is exactly what required should prevent, as there should be no uncertainty over it being called, since the parent method specifically forbids it.

It shouldn’t prevent the use of a conditional, so long as all paths call the super method, i.e:

	if someCondition {
		…
		super.doSomething()
	} else {
		super.doSomething()
		…
	}

Would be fine (both branches call the super method) but a conditional where super is only called in some branches, and nowhere else, is exactly what required is for. You actually raise an interesting question of whether it should be possible to call the super method more than once, that might be a possibility for another requirement, as in most cases it won’t make sense to call it more than once; for example, if you’re extending an add() method then potentially calling super.add() more than once seems like it could lead to unexpected results, and could be an error. For example:

	if someCondition {
		…
		super.doSomething()
	}

	…
	super.doSomething()

Could be a bug where the developer has forgotten to remove the conditional super call; if the parent class knows its method shouldn’t be called more than once per child call then it could prevent this.

> How do you deal with multi-level hierarchies? Do you enforce adding the attribute to the method in the intermediate class? 

It’s up to the developer of the sub-class. As proposed all methods would be final by default, including those overriding a method in a super class, so they would need their own requirements set in order for them to be overridable in the first place.

For example:

	class MyClass {
		@super(require)
		func someMethod() { … }

		@super(require)
		func someOtherMethod() { … }
	}

	class MySubClass : MyClass {
		@super(require)
		override func someMethod() { … } // Can be extended further

		override func someOtherMethod() { … } // Cannot be extended further
	}

> There will be enough edge cases and implementation issues to have subclass implementors cursing it.

Only if the developer of the parent class is over zealous in their choice of restrictions, but you could say the same thing about a bunch of features, like developers who mark almost everything private; like I say, the before and after requirements shouldn’t be very common, while the rest are pretty straightforward. In most cases you’ll either be extending a class that was designed for that purpose, in which case the requirements should be set correctly, or you will be extending a class in your own code base, so can request a change to the requirements (or change them yourself).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160217/d1e7c8d8/attachment.html>