0

Scala overridden fields: are overridden fields also in virtual table?

I'm new to Scala. Conceptually, overridden class methods are in vritual table, but I'm not sure whether overridden fields are also in virtual table?

   class A
   {
        private var str: String = "A"
        val x: A = this

        override def toString(): String = str

        def m1(other: AnyRef): AnyRef = {
          println("This is A.m1(AnyRef)")
          other
        }
    }

    class B extends A {
        private var str: String = "B"
        var z: Int = 0
        override val x: B = this

        override def m1(other: AnyRef): B = {
          println("This is B.m1(AnyRef)")
          this
        }
    }

For the code snippet above, my understanding is that method m1 is in class A and B's virtual table respectively, but I'm not sure whether field x is in virtual table too.

CodingNow
  • 998
  • 1
  • 11
  • 23
  • 1
    public val in scala is translated into a private var field, and a public accessor with the same name. so yes, it's in the vtable. – Jason Hu Feb 24 '18 at 21:40
  • 1
    Or rather, the private field isn't, but the accessor is. I wouldn't say "private var field", but "private JVM field". – Alexey Romanov Feb 25 '18 at 04:31
  • 1
    The behavior of `super.valName` (mentioned [here (similar SO question, 2017)](https://stackoverflow.com/questions/45935672/scala-why-cant-we-do-super-val), [here (archived discussion, 2010)](http://www.scala-lang.org/old/node/8139) and [here (SI-899)](https://issues.scala-lang.org/browse/SI-899)) at least *invokes the impression* as if some simple prefixing-style single inheritance of data fields is used, where `B.v` simply overrides the memory of `A.v` at the same offset. However, this is not really the case: analogous Java examples show that `B` still carries `A.v` around. – Andrey Tyukin Feb 25 '18 at 12:25

0 Answers0