TripleEquals

Provides === and !== operators that return Boolean, delegate the equality determination to an Equality type class, and require no relationship between the types of the two values compared.

This trait will override or hide implicit methods defined by its sibling trait, TypeCheckedTripleEquals, and can therefore be used to temporarily turn of type checking in a limited scope. Here's an example, in which TypeCheckedTripleEquals will cause a compiler error:

import org.scalactic._
import TypeCheckedTripleEquals._

object Example {

 def cmp(a: Int, b: Long): Int = {
   if (a === b) 0       // This line won't compile
   else if (a < b) -1
   else 1
 }

def cmp(s: String, t: String): Int = {
  if (s === t) 0
  else if (s < t) -1
  else 1
}
}

Because Int and Long are not in a subtype/supertype relationship, comparing 1 and 1L in the context of TypeCheckedTripleEquals will generate a compiler error:

Example.scala:9: error: types Int and Long do not adhere to the equality constraint selected for
the === and !== operators; they must either be in a subtype/supertype relationship;
the missing implicit parameter is of type org.scalactic.Constraint[Int,Long]
   if (a === b) 0      // This line won't compile
         ^
one error found

You can “turn off” the type checking locally by importing the members of TripleEquals in a limited scope:

package org.scalactic.examples.tripleequals

import org.scalactic._
import TypeCheckedTripleEquals._

object Example {

 def cmp(a: Int, b: Long): Int = {
   import TripleEquals._
   if (a === b) 0
   else if (a < b) -1
   else 1
 }

def cmp(s: String, t: String): Int = {
  if (s === t) 0
  else if (s < t) -1
  else 1
}
}

With the above change, the Example.scala file compiles fine. Type checking is turned off only inside the first cmp method that takes an Int and a Long. TypeCheckedTripleEquals is still enforcing its type constraint, for example, for the s === t expression in the other overloaded cmp method that takes strings.

Because the methods in TripleEquals (and its siblings)override all the methods defined in supertype TripleEqualsSupport, you can achieve the same kind of nested tuning of equality constraints whether you mix in traits, import from companion objects, or use some combination of both.

In short, you should be able to select a primary constraint level via either a mixin or import, then change that in nested scopes however you want, again either through a mixin or import, without getting any implicit conversion ambiguity. The innermost constraint level in scope will always be in force.