And not a single one has a strong requirement about prohibiting code to be call before or after the super class implementation.
···
Le 25 févr. 2016 à 20:19, Matthew Johnson via swift-evolution <swift-evolution@swift.org> a écrit :
Sent from my iPad
On Feb 25, 2016, at 1:17 PM, Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org> wrote:
Le 25 févr. 2016 à 16:47, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> a écrit :
On 17 Feb 2016, at 22:26, Kyle Sherman via swift-evolution <swift-evolution@swift.org> wrote:
Thanks for the replies.
Kenny: After thinking about it more, discussing with Peter, and looking Haravikk’s comments, I think the best thing would be for this to be a warning as suggested. I respectfully disagree that as a library creator you would not be able to know that a call to super should be required.
I disagree. You can’t possibly know all the use-cases in which your class might be subclassed.
In particular, it is absurd to enforce having the call to super as the first or last line of the method. That would stop me doing things like this:
override func viewDidLoad()
{
print(“About to run super.viewDidLoad()”)
super.viewDidLoad()
print(“Finished super.viewDidLoad()”)
}Then there’s the perfectly reasonable case like this:
override func viewDidLoad()
{
functionThatCallsSuperViewDidLoad()
}Why shouldn’t I be allowed to do that?
+1 with your concern. I’d be curious to see a single real world use case where enforcing first or last is required.
I posted several examples from Apple frameworks in an old thread about this. You might want to look for that message in the archives.