1

In many object oriented languages such as Java, the .NET family, Python, Ruby, and I'm sure a host of others, the root object class from which all other classes inherit defines an equality checking method. However, in my experience, many of the classes I create really don't need an equality check or I (or co-workers) don't bother overriding the default method because we don't intend to use it. In the latter case, the default equality method doesn't represent equality very well for that class. So why do so many languages provide this method as part of the definition of the root object class when it seems like many classes should not? Why not leave off the equality method and force users to define it when they need it?

jpmc26
  • 28,463
  • 14
  • 94
  • 146
  • I would appreciate if someone would explain the downvote. If this question is off topic or otherwise not allowed, I'll remove it. – jpmc26 Jan 17 '13 at 21:44

1 Answers1

1

For any objects references X and Y, regardless of their types, it is possible to meaningfully ask and answer the question "Is the object referred to by X equivalent to the one referred to by Y". If X represents a Porche 911 automobile and Y represents a cast-iron park bench, the answer would simply be "no". To be sure, if one knew that X was a car and Y a bench, one likely wouldn't bother asking, but suppose X, Y, or both, were "things that one may be asked to paint". One might not know whether or not X and Y are of the same type, and the objects are not equivalent, one may not care. Having a universal means of asking equivalence saves code the trouble of having to worry about objects' exact type.

The reason to have all objects implement Equals as a virtual method is that it's the easiest mechanism by which objects can supply a definition of equivalence that is broader than referential equality. It is often useful to have immutable objects report themselves as equivalent to other objects which have the same immutable state [e.g. having two strings, both holding the six characters "GEORGE", reported each other as equivalent] Having all objects implement Equals as a virtual method, and having mutable objects' implementation simply report referential equality, is generally easier than having an Equals function which can only be used on immutable objects. After all, it's not hard for an mutable object to simply report itself as unequal to anything other than itself.

supercat
  • 77,689
  • 9
  • 166
  • 211
  • This is a fair point. However, it seems to me that we can deal with this using normal object-oriented practices. In statically typed languages, one could implement an interface. In your particular example, it could be `Paintable` or `IPaintable` or what have you depending on language conventions, and this interface would probably extend an interface defining an equals method (`Equatable` or `IEquatable` perhaps). In dynamic languages, I suppose duck typing conventions would dictate that you try calling equals and letting it blow up if it doesn't define an equals method. Am I missing something? – jpmc26 Jan 18 '13 at 23:31
  • One thing I think you're missing is that if one doesn't require all objects to implement an equivalence test, then every interface `IFoo` must either (1) require all implementations to provide an equivalence test, or (2) require that code wanting to test equivalence of two `IFoo` references must cast to something else. Given that any class object that implements `IFoo` *can* (like any object that doesn't) implement an equivalence test, option #1 is better than #2, but if just about every interface is going to require an equivalence test, one may as well bite the bullet and make it universal. – supercat Jan 18 '13 at 23:53
  • @jpmc26: See above. Also, although I understand from a performance perspective why a framework allows arbitrary references to be tested for referential equality, I would posit that from a pure OOP perspective, the only such test which would be permitted would be to see if a reference was null; code should generally neither know nor care whether two `String` references point to the same instance. Knowing whether two objects are *equivalent* is a legitimate thing for code to want to know, but whether equivalence implies referential equality is (aside from performance) not. – supercat Jan 19 '13 at 00:06
  • I suppose whether or not it's a good idea is debatable. This is probably the reasoning behind the decision, though. – jpmc26 Jan 22 '13 at 19:37