0

Let me explain my observation in scala about multiple inheritance-

Multiple inheritance is not possible in scala for classes. I can understand this is due to "Diamond Problem" http://stackoverflow.com/questions/2064880/diamond-problem so below code does not compile

    class High {
  def confuse(){
    println("High::I will confuse you later")
   }
}
class MiddleLeft extends High {
  override def confuse(){
    println("MiddleLeft::I will confuse you later")
   }
}
class MiddleRight extends High{
 override def confuse(){
    println("MiddleRight::I will confuse you later")
   }
}

// Below code does not compile
class LowLeft extends MiddleRight  with MiddleLeft{
  def calConfuse(){
    confuse()
  }
}

Now traits might have concrete classes. But it supports multiple inheritance because order of how traits are extended does matter which solve the diamond problem , so below code works properly

trait High {
  def confuse(){
    println("High::I will confuse you later")
   }
}
trait MiddleLeft extends High {
  override def confuse(){
    println("MiddleLeft::I will confuse you later")
   }
}
trait MiddleRight extends High{
 override def confuse(){
    println("MiddleRight::I will confuse you later")
   }
}

class LowLeft extends MiddleRight  with MiddleLeft{
  def calConfuse(){
    confuse()
  }
}
class LowRight extends MiddleLeft with MiddleRight{
  def calConfuse(){
    confuse()
  }
}

object ConfuseTester extends App{
  val lowLeft:LowLeft=new LowLeft()
  lowLeft.confuse() //prints>>>MiddleLeft::I will confuse you later
  val lowRight:LowRight=new LowRight()
  lowRight.confuse()//prints>>>MiddleRight::I will confuse you later
}

My question is why multiple inheritance for classes does not follow same strategy like trait does(Ordering of how those are extended)

Goutam Chowdhury
  • 271
  • 1
  • 3
  • 12
  • 2
    Classes have constructors, traits don't. It'd be impossible to satisfy both multiple constructors in some cases. – 0x6C38 Dec 09 '16 at 23:31
  • Traits can have "constructors" (initializers) in Dotty and Scala 2.12. If you look at the restrictions trait initializers have compared to class constructors, you can get some hints about the things that can break if you allow multiple inheritance for classes. But really, the main thing is: multiple inheritance for classes has a specific meaning, namely a class which has multiple superclasses. That's not what trait mixins do: trait mixins only have *one* supertrait, they just don't know which one. Redefining class multiple inheritance to mean the same thing as trait mixins is certainly … – Jörg W Mittag Dec 10 '16 at 11:32
  • … possible, but it would no longer be class multiple inheritance, it would be trait mixins, and the classes would no longer be classes, they would be traits or mixins, and still calling them classes would just lead to confusion. With MI, a class appears *once* in the inheritance "tree" (really, a DAG with MI) and has *multiple* superclasses, a trait mixin appears *multiple times* in the inheritance tree and has only *one* supertrait (although a different one at each point it appears). The two are exactly dual to one another. – Jörg W Mittag Dec 10 '16 at 11:33

1 Answers1

1

Each Scala class is compiled to a single JVM class, and JVM doesn't support multiple inheritance for classes.

Alexey Romanov
  • 167,066
  • 35
  • 309
  • 487
  • That's an implementation detail of one particular implementation of Scala. E.g. Scala.js doesn't compile to classes at all, yet has the same restriction. Scala-native is completely free to define any encoding scheme for traits and classes it wants, yet has the same restriction. Also, you can compile traits with Scala-JVM, even though the JVM doesn't have traits, so it sure seems possible to choose a similar encoding for classes. – Jörg W Mittag Dec 10 '16 at 11:29
  • For the first argument: as far as I know the only implementation nearly as old as JVM Scala was CLR Scala (now abandoned), and the same argument would apply there. Scala.js and Scala-native both appeared long after this limitation was set in Scala specification, and don't have a reason to actively break compatibility in this specific respect (and couldn't reuse as much of JVM Scala's implementation as they currently can if they did). – Alexey Romanov Dec 10 '16 at 12:19
  • For the second: I expect that if Odersky and his coauthors _had_ come up with such an encoding, and without undesirable limitations, it would have been used and maybe Scala wouldn't even have traits. But they didn't, so it wasn't. This doesn't mean it's _impossible_, but it certainly seems hard to achieve. – Alexey Romanov Dec 10 '16 at 12:29