Equals and value types

[cronusf]

In my book they give a sample Complex class implementation and it
implements:

override bool Equals(object rhs)
{...}

public book Equals(Complex rhs) // IEquatable<Complex>
{...}

public static bool operator==(Complex lhs, Complex rhs)
{...}

My question is, what is the point of implementing Equals when
operator== is defined?

Also, when would the "object" version of Equals ever be called instead
of the specific type version? Obviously it would be called if you
passed an object, but I can't see why that would ever happen in
practice.

 

[Jon Skeet [C# MVP]]

In my book they give a sample Complex class implementation and it
implements:

override bool Equals(object rhs)
{...}

public book Equals(Complex rhs) // IEquatable<Complex>
{...}

public static bool operator==(Complex lhs, Complex rhs)
{...}

My question is, what is the point of implementing Equals when
operator== is defined?

Because otherwise hash tables won't work properly - or anything else
which calls Equals.

Also bear in mind that Equals is applied polymorphically whereas ==
isn't.

Also, when would the "object" version of Equals ever be called instead
of the specific type version? Obviously it would be called if you
passed an object, but I can't see why that would ever happen in
practice.

It *often* happens in practice - any time a piece of code compares two
objects without knowing their types at compile-time. Finding an entry
in a list, or looking up a key in a hashtable are the most obvious
examples.