7

Assuming I am designing a collection of objects for use by others and assuming I have read and understood (huh?) most threads about the differences between operator== and Equals(), WHY should I ever implement operator==?

Stealing an example from this thread, using it can be quite error prone:

object x = "hello";
object y = 'h' + "ello"; // ensure it's a different reference
(x == y); // evaluates to FALSE
string x = "hello";
string y = 'h' + "ello"; // ensure it's a different reference
(x == y); // evaluates to TRUE

So, can I tell my users to just use Equals() and ReferenceEquals() and that's it? What am I missing there?

  • Are there maybe pieces of the standard code base that use == and there is no way around it?

  • Is the == performance a lot better in some important cases? (well, ok, Equals is a virtual so it's gonna be a bit slower all the time, but i cannot see any use case where this actually becomes a bottleneck)

  • something else?
Community
  • 1
  • 1
Gurg Hackpof
  • 1,304
  • 1
  • 13
  • 26

4 Answers4

8

You can tell your users just to use Equals... but I for one find it very handy that various types (including String) overload ==. Yes, you need to be aware of the way that overload resolution works, but for most experienced developers I suspect that isn't a problem most of the time, whereas:

if (Equals(x, y))

ends up looking nastier than

if (x == y)

in my view. Note that these are both different to

if (x.Equals(y))

which will blow up if x is null, of course...

If you prefer not to overload == then it's not like anything will fail - you just may get disgruntled users.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
2

You implement == as a convenience for the users of your API. If you feel so strongly that users of your API would be confused by it, then don't implement it. Personally I would disagree with you, but it's your decision at the end of the day.

Christian Hayter
  • 30,581
  • 6
  • 72
  • 99
0

WHY should I ever implement operator==?

For the convenience of the users of your type. If you are the only user, and you're happy to always test equality by invoking Equals, then you don't need to.

But if you were implementing, say, a complex number type1, I as a consumer of your type would be extremely disappointed to discover I couldn't do:

var z = new Complex(1, 0);
var c = new Complex(1, 0);
var eq = z == c;

but intead had to say

var eq = Complex.Equals(z, c);

1 I know there is one...

AakashM
  • 62,551
  • 17
  • 151
  • 186
0

For me it's a question of what I generally want to do with the objects.

Take strings for example. In 99% of all cases you compare two strings to check for equality and not whether both variables point to the same string.

You also write:

int x, y;
if( x == y ) ..

So why would you want to force yourself to use:

BigNum x, y;
if( x.Equals(y) ) ...

Of course it's a source of errors (as most operator overloading is), but I think given the right context (e.g. an object where it's obvious you'd want to compare it's value) then it's a good thing to overload. If it's ambiguous then I'd always stick to Equals() and not overload ==.

s3rius
  • 1,442
  • 1
  • 14
  • 26