Trait final methods


#1

Using final methods of traits is dangerous.

For example, let we have:

 
trait A {
    fun f() {}
}

trait B {
  fun f() {}
}

class C: A, B {
  override fun f() {
  super<A>.f()
  }
}

Now, let fun f() in A is final. We have an error:

 
trait A {
    final fun f() {}
}

trait B {
  fun f() {}
}

class C: A, B {
  override fun f() { // Error: ‘f’ in ‘A’ is final and cannot be overridden
  super<A>.f()
  }
}

As mentoined in http://stackoverflow.com/questions/23453287/why-is-final-not-allowed-in-java-8-interface-methods/23476994#23476994 thats why java 8 forbid final default methods in interfaces.

Why kotlin allow this?


#2

The answer by Brian Goetz that you refer to clearly says:

The key thing to understand about default methods is that the primary design goal is interface evolution, not "turn interfaces into (mediocre) traits".   

Kotlin's goal is different, that's why


#3

I must note here that we are still investigating compatibility issues that may arise from the new features introduced in Java 8. This may lead us to withdrawing some features from Kotlin, and final members in traits is one such candidate


#4

Thanks for answer!

How do you think, should I use final methods in traits in real projects for now?
Or it is better to avoid this?


#5

If it scares you, I'd avoid them