The code:
Set(1) == List(1)
will always return false but will also always compile. This is pathological.
"Equality in Scala is a mess ... because the language designers decided Java interoperability trumped doing the reasonable thing in this case." (from here).
There are ways of solving this problem, the simplest being to use === that a number of libraries offer. Here are a three different ways of doing it:
def scalazTripleEquals(): Unit = {
import scalaz._
import Scalaz._
// println(List(1) === List("1")) // doesn't compile :)
}
def scalaUtilsTripleEquals(): Unit = {
import org.scalautils.TypeCheckedTripleEquals._
// println(List(1) === List("1")) // doesn't compile :)
}
def scalacticTripleEquals(): Unit = {
import org.scalactic._
import TypeCheckedTripleEquals._
// println(List(1) === (List("1"))) // doesn't compile :)
}
But what about incorporating it into the Scala language itself?
Scala creator, Martin Odersky's views can be found here here. He is proposing "it is opt-in. To get safe checking, developers have to annotate with @equalityClass ... So this means we still keep universal equality as it is in Scala now - we don’t have a choice here anyway, because of backwards compatibility."
Warning: ScalaTest
There is a horrible gotcha using Scalactic and ScalaTest (which is odd since they are stable mates). The problem is that you want compilation to fail for something likes this:
import org.scalatest.{FlatSpec, Matchers}
class MyTripleEqualsFlatSpec extends FlatSpec with Matchers {
"triple equals" should "not compile" in {
List(1) should === (List("1"))
}
}
Only it doesn't. It happily compiles! This is not what was expected at all given the code in scalacticTripleEquals() above. The solution can be found here. You must change the class signature to:
class MyTripleEqualsFlatSpec extends FlatSpec with Matchers with TypeCheckedTripleEquals {
for the compiler to detect this error.
Arrays
As an addendum, I just discovered Scala gives a nice way to compare arrays by value rather than by reference. It's:
a.deep == b.deep
(see here).
No comments:
Post a Comment