scala，初始化抽象vals

Question

the book "Programming in Scala, Third Edition, Martin Odersky" gives this example on page 449:

trait RationalTrait {
  val numerArg: Int
  val denomArg: Int
  require(denomArg != 0)
  private val g = gcd(numerArg, denomArg)
  val numer = numerArg / g
  val denom = denomArg / g
  private def gcd(a: Int, b: Int): Int =
    if (b == 0) a else gcd(b, a % b)
  override def toString = numer + "/" + denom
}

and then it explains that the following code fails because the trait is initialized before the anonymous class, and so, denomArg is still 0.

new RationalTrait {
  val numerArg = 4
  val denomArg = 24
}

and it provides two solutions. One solution is to use pre-initialized fields:

new {
  val numerArg = 4
  val denomArg = 24
} with RationalTrait

the second solution is to modify the trait to use lazy values, as follows:

trait LazyRationalTrait {
  val numerArg: Int
  val denomArg: Int
  lazy val numer = numerArg / g
  lazy val denom = denomArg / g
  override def toString = numer + "/" + denom
  private lazy val g = {
    require(denomArg != 0)
    gcd(numerArg, denomArg)
  }
  private def gcd(a: Int, b: Int): Int =
    if (b == 0) a else gcd(b, a % b)
}

new LazyRationalTrait {
  lazy val numerArg = 4
  lazy val denomArg = 24
}

However, this simpler solution also works. I wonder why they did not mention this solution. Is there any drawback in this?

new RationalTrait {
  lazy val numerArg = 4
  lazy val denomArg = 24
}

Answer 1

I would consider your solution as more consistent comparing to the second option (mentioned on page 453 of Programming Scala, 3d ed.):

trait A { 
  val x: Int 
  lazy val y: Int = x
  val z: Int = y 
}

new A { val x = 1 }.y        // ==0 ?!!!
new A { val x = 1 }.z        // ==0 ?!!!

vs

trait A { 
  val x: Int 
  val y: Int = x
  val z: Int = y 
}

new A { lazy val x = 1 }.y   // ==1
new A { lazy val x = 1 }.z   // ==1

At least I don't need to remember that lazy val s can't be used in non-lazy constructs in the base class. Looking at the bytecode I don't see any obvious problems with your approach since in the latter case x is effectively defined as def so it already exists when initialization starts in the base class.