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.
Equivalenceenables you to define alternate notions of equality for types that can be used with ScalaUtil'sTypeCheckedTripleEqualsandConversionCheckedTripleEqualstraits. 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 ofMatcherstrait.Because
EqualityextendsEquivalence, you automatically define anEquivalence[T]when you define anEquality[T]. Most often you will usually want to define customEqualitys, because they will be more generally useful: they are also used by Scalactic'sTripleEqualstrait and ScalaTest'sequal,be, andcontainmatcher syntax. However, if you really want just anEquivalence, and writing anEqualityis inconvenient, you can write anEquivalencedirectly for a type.For example, say you have a case class that includes a
Doublevalue:Imagine you are calculating the
agevalues 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 ofTypeCheckedTripleEqualslooks for an implicitEquivalence[SUPER], whereSUPERis 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'sequalsmethod. Thatequalsmethod, provided by the Scala compiler becausePersonis 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 theageDoubles with a tolerance, like this:Now the
===operator will use your more forgivingEquivalence[Person]for the equality check instead of default equality:scala> Person("Joe", 29.0001) === Person("Joe", 29.0) res1: Boolean = true