#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: |
Description
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." - http://msdn.microsoft.com/en-us/magazine/cc301569.aspx
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 14 years ago by gkronber
comment:2 Changed 14 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 14 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.
comment:4 Changed 14 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 14 years ago by swagner
- Milestone changed from Iteration 4 to Current
Milestone Iteration 4 deleted
comment:11 Changed 14 years ago by swagner
- Milestone changed from Current to HeuristicLab 3.3.0
Milestone Current deleted
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.