10

Why GetHashCode is not a property like HashCode in .NET?

Joan Venge
  • 315,713
  • 212
  • 479
  • 689

6 Answers6

19

Probably because it requires computation, and exposing it as a propery might imply that the hashcode is already available for free.

Edit: Guidelines on this: Properties versus Methods

"The operation is expensive enough that you want to communicate to the user that they should consider caching the result."

Perhaps GetHashCode is expensive enough in some cases.

MichaelGG
  • 9,976
  • 1
  • 39
  • 82
  • Thanks, is there a guideline for not having properties that requires computation? The reason I ask is, I have seen lots that computes when you access the property. – Joan Venge Feb 11 '09 at 20:55
4

I don't think there's any good reason. Any implemention of GetHashCode should be fast enought to put into a property. That said, there are plenty of design flaws in the .Net framework, some small, some serious. This seems like a small one.

Community
  • 1
  • 1
Scott Weinstein
  • 18,890
  • 14
  • 78
  • 115
2

Often it is not possible to define a HashCode for a class that makes since:

e.g. the objects of the class don’t have a well defined concept of identity.

Therefore it is common to make the GetHashCode() method throw a NotImplementedException. This would course all sort of problem if HashCode was a property, as most people (and debuggers) assume it is always valid to get the value of a property

Ian Ringrose
  • 51,220
  • 55
  • 213
  • 317
  • 1
    Nearly all class objects should generally either have reference semantics or immutable value semantics. Objects with reference semantics have a clear concept of identity (object X and object Y are equal if and only if X and Y refer to the same object). Objects with immutable value semantics have a clear concept of identity (object X and object Y are equal if they hold equal values). What types of object wouldn't have a well-defined concept of identity? – supercat Dec 21 '11 at 01:18
  • @supercat, Equals should only return true for object with the same HashCode, however often I see an equals method defined just for the use of unit tests on obejct that are not immutable. So to stop the warning from the compiler, GetHashCode() must be overridden, however know the object should never be used as a key. Without a usefull equals method on objects, the assets on collections in nUnit don't work. – Ian Ringrose Dec 22 '11 at 10:12
  • That would be a definite abuse of Object.Equals(). Actually, I wish the method had been named Equivalent(), rather than Equals(), since it is the concept of equivalence, rather than the name, which is universally applicable, and in some cases it might be useful for some objects to have an Equals() method with looser semantics. For example, if I had my druthers, Equivalent(1.00m, 1.0m) would be false, but Equals(1.00m, 1.0m) would be true. Equals would be defined by spec as a transitory property, unlike Equivalent which would be (whenever implemented properly) immutable. – supercat Dec 22 '11 at 14:17
1

Besides that a property is nothing else than a getter and a setter method, from a design perspective a property should never contain any computations other than initializing or validation, eg:

private object _obj;
public object Obj
{
  get
  {
    if(_obj == null)
    {
      _obj = new object();
    }
    return _obj;
  }
  set
  {
    if(value == badvalue)
    {
      throw new ArgumentException("value");
    }
    _obj = value;
  }
}

GetHashCode() does not contain extensive computations, but it could contain such long running operations (just from the fact that it could compute the hashcode of an object in a complex manner), this is why its a method instead of a property.

haze4real
  • 728
  • 1
  • 9
  • 19
0

properties should only be used if the computation behind them is really fast or cached

besides most of the time the only logic in properties should be validation

LDomagala
  • 2,193
  • 4
  • 20
  • 34
-2

You have to remember that the .NET Framework is designed to be accessed by a wide variety of languages.

In theory you could create a compiler that is incapable of correctly overriding properties. While that would make for a pretty crappy compiler, it would not necessarily be illegal. (Remember properties are just methods with some meta data)

Guvante
  • 18,775
  • 1
  • 33
  • 64
  • 1
    You could also make a compiler that can't override methods. And plenty of other .NET interfaces require overring a property. – MichaelGG Feb 11 '09 at 21:16
  • 1
    Plenty of interfaces require overriding a property, but Object is the grandfather of everything, why not keep it simple? – Guvante Feb 12 '09 at 19:06