interactions between operator== and the two Object.Equals methods

[emma middlebrook]

Hi

Having difficulty getting myself clear on how a type's operator== fits
in with Object.Equals.

Let's just consider reference types.

The default operator== tests for object identity (reference)
equivalence. You can override it if you like.

Object has ... public virtual bool Equals(object);

The default implementation also gives you a reference equality test.
You can override it if you like.

So ... why two different ways of achieving the same thing? What's one
for? What's the other for? When would you override one? When would you
override the other? I'm asking how these two methods are the same and
also how they are different!!! Let's just consider reference types
only.

I did notice if you implement IComparable you must provide an
implementation of Equals.

I also noticed this advice (Object.Equals help): "if your programming
language supports operator overloading and if you choose to overload
the equality operator for a given type, that type should override the
Equals method. Such implementations of the Equals method should return
the same results as the equality operator."

If they need to be consistent why *two* different ways to achieve the
same functionality - isn't this asking for trouble?!

And then it says this seemingly contradictory quote: "most reference
types should not overload the equality operator, even if they override
Equals."

Eek - it's pretty clear now that I need some help from someone
understanding the rationale behind == and .Equals!!!

As a finale, what's the point of the static Equals method on Object?
public static bool Equals(object objA, object objB);

What does it do that objA.Equals(obj B) would not achieve?

Cheers for listening and hope someone can help my lack of
understanding!

Emma Middlebrook
emma_middlebroo k@fastmail.fm

[Anders Borum]

Re: interactions between operator== and the two Object.Equals methods

Hello!

Equals is also used when comparing e.g. strings. You can implement your own
ways to compare objects. A wellknown fact, but I just wanted to point it out
to you! :)

--
venlig hilsen / with regards
anders borum
--

[Michael Mayer]

Re: interactions between operator== and the two Object.Equals methods


"emma middlebrook" <emma_middlebro ok@fastmail.fm> wrote in message
news:e27ae805.0 308040906.6fec2 faf@posting.goo gle.com...
Hi
[color=blue]
> Having difficulty getting myself clear on how a type's operator==[/color]
fits[color=blue]
> in with Object.Equals.[/color]

I suspect some of the confusion comes from the fact that not all .Net
languages support operator overloading (e.g. vb.net). Those langauges
will still allow you to override object.Equals. In C# we get the
additional benefit of having more concise code.

That is, if we implemented ComplexNumber as a class (even though a
struct probably makes more sense):
ComplexNumber a = new ComplexNumber (10, 20);
ComplexNumber b = new ComplexNumber (10, 20);

we could override equals to provide syntax like
a.Equals(b)
in order to get value-type equality checking.
We should also override the static method so that
a.Equals(b) is the same as ComplexNumber.E quals(a,b);

In C#, we would probably want to override the operator also, thus
(a==b) would return true.

I believe the online help was saying that if you've changed the ==
operator to make it more convenient to compare using value-type
semantics, then you should change the Equals method so that they both
"do the same thing". That is, it would be disturbing in the above
example if
a==b returned true but a.Equals(b) returned false. That would only
happen if you overload the operator but forget the method.

For most reference types, overloading the operator == is a bad idea,
IMO. Other languages will assume that the == operator means reference
type equality. They would only be used to Equals() to test for value
equality.

In the above example, it would be fine to have an implementation
whereby
a.Equals(b) = true (since they have similar values)
but have a == b still performing reference equality and hence return
false (since the two objects are unique instances of ComplexNumber).

I guess the help should have said that (a == b) should always behave
the same as either a.Equals(b) or Object.Referenc eEquals(a,b), with
the preference being ReferenceEquals .

HTH,
Mike