Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#1137 closed enhancement (rejected)

Primitive type wrappers should override Equals and GetHashCode

Reported by: svonolfe Owned by: swagner
Priority: low Milestone: HeuristicLab 3.3.0
Component: Data Version: 3.4
Keywords: Cc:


When two wrappers like IntValues with the same primitive value are compared, the Equals method returns false, also a different hash code is returned.

In my point of view Equals and GetHashCode should be overwritten for primitive type wrappers because the .NET provided wrappers (derived from System.ValueType) override the equals method: "Value types are implicitly derived from System.ValueType. This type offers the same methods as defined by System.Object. However, System.ValueType overrides the Equals method so that it returns true if the values of the two objects' instance fields match. In addition, System.ValueType overrides the GetHashCode method so that it produces a hash code value using an algorithm that takes into account the values in the objects' instance fields. When defining your own value types, it is highly recommended that you override and provide explicit implementations for the Equals and GetHashCode methods." -

Of course it can be discussed if wrappers should be regarded as value or as reference types in the HL framework. To me it seems confusing regarding the IntValue wrapper as a reference type because for example List<IntValue> methods like IndexOf or Contains do not work.

Change History (6)

comment:1 Changed 10 years ago by gkronber

IntValue and comparable classes are no value-types because they are also Items. Items are by definition no value types as multiple items with the same internal values can and should exist side by side!

Just think about it this way: two IntValues with the value "3" are displayed in the GUI. By your suggestion they should be the same object. However, what happens if I want to change one of them? It's only possible if they are treated as reference types.

comment:2 Changed 10 years ago by gkronber

Also your argument about the way the wrappers in .NET are implemented fails because they are structs (= value types) and not classes.

comment:3 Changed 10 years ago by svonolfe

I agree to the point that IntValues should not be regarded as value types (i.e. not implemented as structs) considering your argument. When regarding IntValues as reference types, the msdn recommendation is not applicable in that case (it refers to value types).

However, if you think about boxing and unboxing, Equals returns true when value types are converted to reference types. Isn't that what those wrappers in HL do?

object o1 = 5
object o2 = 5
o1.Equals(o2) //true

If Equals and GetHashCode would be overwritten, two IntValues with the same primitive value would not be the same object (identical), they would be equal implemented as reference types.

Last edited 10 years ago by svonolfe (previous) (diff)

comment:4 Changed 10 years ago by svonolfe

  • Resolution set to wontfix
  • Status changed from new to closed

mkommend pointed out that overwriting the Equals and GetHashCode methods would cause problems because the wrappers are not immutable. For example if an IntValue would be stored in a HashTable and then the internal value would be changed, it would never be found in the HashTable again...

comment:5 Changed 10 years ago by swagner

  • Milestone changed from Iteration 4 to Current

Milestone Iteration 4 deleted

comment:11 Changed 10 years ago by swagner

  • Milestone changed from Current to HeuristicLab 3.3.0

Milestone Current deleted

Note: See TracTickets for help on using tickets.