Indicates whether the objects passed as a
and b
are equal.
Indicates whether the objects passed as a
and b
are equal.
Note: this areEquivalent
method means essentially the same thing as the areEqual
method
of trait Equality
, the difference only being the static type of the
right-hand value. This method is named areEquivalent
instead
of areEqual
so that it can be implemented in terms of areEqual
in trait
Equality
(which extends Equivalence
).
a left-hand-side object being compared with another (right-hand-side one) for equality (e.g., a == b
)
a right-hand-side object being compared with another (left-hand-side one) for equality (e.g., a == b
)
true if the passed objects are "equal," as defined by this Equivalence
instance
Defines a custom way to determine equality for a type when compared with another value of the same type.
Equivalence
enables you to define alternate notions of equality for types that can be used with ScalaUtil'sTypeCheckedTripleEquals
andConversionCheckedTripleEquals
traits. These traits can be used to perform equality comparisons with type constraints enforced at compile time using ScalaUtil's===
and!==
syntax and ScalaTest'sshould
===
syntax ofMatchers
trait.Because
Equality
extendsEquivalence
, you automatically define anEquivalence[T]
when you define anEquality[T]
. Most often you will usually want to define customEquality
s, because they will be more generally useful: they are also used by ScalaUtils'TripleEquals
trait and ScalaTest'sequal
,be
, andcontain
matcher syntax. However, if you really want just anEquivalence
, and writing anEquality
is inconvenient, you can write anEquivalence
directly for a type.For example, say you have a case class that includes a
Double
value:Imagine you are calculating the
age
values in such as way that occasionally tests are failing because of rounding differences that you actually don't care about. For example, you expect an age of 29.0, but you're sometimes seeing 29.0001:The
===
operator ofTypeCheckedTripleEquals
looks for an implicitEquivalence[SUPER]
, whereSUPER
is either the left-hand or right-hand type, whichever one is a supertype of the other. In this case, both sides arePerson
(which is considered a supertype of itself), so the compiler will look for anEquivalence[Person]
. Because you didn't specifically provide an implicitEquivalence[Person]
,===
will fall back on default equality, because anEquality[Person]
is-anEquivalence[Person]
. The defaultEquality[Person]
will callPerson
'sequals
method. Thatequals
method, provided by the Scala compiler becausePerson
is a case class, will declare these two objects unequal because 29.001 does not exactly equal 29.0.To make the equality check more forgiving, you could define an implicit
Equivalence[Person]
that compares theage
Double
s with a tolerance, like this:Now the
===
operator will use your more forgivingEquivalence[Person]
for the equality check instead of default equality: