Will the var members in case class affect case cla

Question

I have made heavy use of case classes in my code, replying on the underlying equality definitions of case class to behave correctly. Then now I found that I need to add another field member to a case class.

1. So if I add a var field member in case class, will it mess up the equality attributes for the case class?
2. If 1 is yes, then what if I just change the var field value once, after that, no any reassignment will happen, before the case class goes into any collections or do equality comparison, will that still mess up the equality behaviors?

Answer 1

Case class equality is based solely on its primary constructor attributes, whether they're var or val (yes, you can make them var by giving an explicit var to override the implied val that case class constructor args possess.) Adding properties in the body of a case class does not influence the compiler-generated equals(other: Any) method.

Witness:

package rrs.scribble

object  CCVarEq
{
  case class CC1(i: Int, j: Float, var k: Double)

  case class CC2(i: Int, j: Float, var k: Double) {
    var l = math.Pi
  }

  def show {
    val cc11 = CC1(1, 2.0f, 3.0)
    val cc12 = CC1(1, 2.0f, 3.0)

    val cc21 = CC2(1, 2.0f, 3.0); cc21.l = math.E
    val cc22 = CC2(1, 2.0f, 3.0)

    printf("cc11 == cc12: %s%n", cc11 == cc12); cc12.k = math.Pi * math.E
    printf("cc11 == cc12: %s%n", cc11 == cc12)

    printf("cc21 == cc22: %s%n", cc21 == cc22)
  }
}

In the REPL:

scala> import rrs.scribble.CCVarEq._
import rrs.scribble.CCVarEq._

scala> show
cc11 == cc12: true
cc11 == cc12: false
cc21 == cc22: true

And all jamie's points about concurrency are valid, too.

Answer 2

It's not that simple. You update a case class var on one thread, and another thread is performing an equality check. Unless the var is volatile, it's plausible that the change to the var won't be propagated to the other thread before the equality check is performed. So you could have race conditions. Regardless if this happens only once or many times.

Is the value to be changed once undefined up to that point? If so, use a lazy val. It has a synchronization concern that could slow high-performance code, but would otherwise meet your use case.