hmmm, now I'm even more confused. Perhaps somebody else from my office will
locate the links we found that partially agree and partially contradict what
you have to say here, and hopefully I'm remembering it all correctly now.
Does the clr use GetHashCode to determine instance equality with the ==
operator?
We found that what you are saying is correct for use of GetHashCode for use in
hashtables, but that in general, the GetHashCode value should remain the same
as long as the instance is the same instance. That's dual definintion is ugly
of course, but the second part is much more meaningful than semantics that try
to keep GetHashCode and Equals in step. I admit to being heavily influenced by
java on this point, but this definition is exactly what I want the .net
definition to be.
MyObject a = new MyOjbect("a");
MyObject b = new MyObject("b");
MyObject c = new MyObject("a");
MyObject d = b;
a == b //false
a.Equals(b) //false
a == c //false
a.Equals(c) //true
a.GetHashCode() == c.GetHashCode() //false
b == d //true
b.GetHashCode() == d.GetHashCode() //true
b.Value = "a";
a == b //false
a.Equals(b) //true
.Equals is the semantic equality, ie they are different instances that mean the
same thing.
GetHashCode is use to determine whether they are the same instance
We did find documentation to back this view up, and it contradicts the view in
this thread the GetHashCode forces you to make your objects immutable and from
what you are saying we can find documentation to back up any point of view we
want.
--- Ian Griffiths <[EMAIL PROTECTED]> wrote:
> > special code needs to exist to ensure that once GetHashCode()
> > has returned a value, that object instance must always return
> > the same value from later GetHashCode calls.
>
> Nope. I know the docs say that GetHashCode must always return the same
> value, but they are wrong.
>
> See the "Documentation Rant" section in the second half of this:
>
> http://www.interact-sw.co.uk/iangblog/2004/06/21/gethashcode
>
>
> If you choose to follow the 'rule' that GetHashCode must always returns
> the same value, and for which you don't have a trivial GetHashCode that
> always returns a constant value, this commits you to writing immutable
> objects. (Or at least objects which can never change in a way that
> would change the outcome of Equals comparisons.)
>
> But as the posts from Microsoft employees linked to in that article
> above point out, that's not actually the intent. GetHashCode is allowed
> to return different values over time.
>
> For example, look at the IPAddress class:
>
> IPAddress ip = new IPAddress(0x12345678);
> IPAddress ip2 = new IPAddress(0x12345678);
> Console.WriteLine(ip.Equals(ip2));
> Console.WriteLine(ip.GetHashCode());
> Console.WriteLine(ip2.GetHashCode());
> Console.WriteLine();
>
> ip.Address = 0x87654321;
> Console.WriteLine(ip.Equals(ip2));
> Console.WriteLine(ip.GetHashCode());
> Console.WriteLine(ip2.GetHashCode());
> Console.WriteLine();
>
> IPAddress ip3 = new IPAddress(0x87654321);
> Console.WriteLine(ip.Equals(ip3));
> Console.WriteLine(ip3.GetHashCode());
> Console.WriteLine();
>
>
> When I run this I get:
>
> True
> 305419896
> 305419896
>
> False
> -2023406815
> 305419896
>
> True
> -2023406815
>
>
> Initially the two objects have the same value, so they compare as equal,
> and of course they therefore have the same hash code.
>
> I then change one of the values. (Note I'm not changing the object -
> it's the same pair of objects, I'm just mutating one of them.) It would
> make no sense for them to compare as equal now, and indeed we see
> 'False' returned.
>
> Notice that the hashcode of ip1 is now different. Why is it different?
> Well, what if we were to create a brand new IPAddress that happens to
> have the second address? Would you expect this third object to have the
> same hash as ip2, despite having a different value? How would you
> enforce that, other than by giving everything the same hashcode?
>
> Of course the third IPAddress object has the same address as the new
> address we gave the original ip object, so they both compare Equals as
> you see. And this of course requires them to have the same hash code.
>
> Note that this means you CANNOT store the original hash value and return
> it forever. If you do that you'll be breaking the rule that says "If
> Equals says two objects are equal, they must have the same hash code."
> This rule means that since the modified 'ip' object is equal to the
> 'ip3' object, they must have the same hash code. If 'ip' had held onto
> its original hashcode, it would be violating this rule.
>
>
> (Of course you might be wondering how I'm deciding which of the two
> mutually contradictory rules for GetHashCode it's safe to ignore, well
> first I refer you back to Brad Abrams post... But second, consider why
> these 'rules' were written - they're both for the benefit of hashtables.
> Hashtables require that equality of Equals always means equality of
> hashcodes. Hashtables also require that the hashcodes of objects use as
> keys do not change while. That's the rationale for the rule. However,
> you can also guarantee those two rules by ensuring that you stick to the
> 'equals implies same hashcode' rule, and by never modifying any object
> that's in use as a key.)
>
>
> So if you want to write mutable objects that implement GetHashCode you
> have two choices. (1) your GetHashCode could return a constant value,
> the same for all instances regardless of value, or (2) your object's
> hash code must change when the value changes in a way that affects the
> outcome of Equals.
>
>
> --
> Ian Griffiths
> http://www.interact-sw.co.uk/iangblog/
>
> > -----Original Message-----
> > From: Unmoderated discussion of advanced .NET topics.
> [mailto:ADVANCED-
> > [EMAIL PROTECTED] On Behalf Of J. Merrill
> > Sent: 27 June 2005 20:37
> > To: [email protected]
> > Subject: Re: [ADVANCED-DOTNET] GetHashCode() method
> >
> > At 02:49 PM 6/27/2005, Frans Bouma wrote (in part)
> > >> There's been some discussion lately regarding the
> > >> Object.GetHashCode() method.
> > >>
> > >> I think the concensus is pretty clear: for best reliability,
> > >> classes that implement GetHashCode() should be immutable.
> > >
> > > Why? you can also get dupes with GetHashCode. It's not as if
> it's
> > a magic value. The point is though that if you use it for
> identification,
> > realize that the identification is not unique, as a risk for dupes is
> > there.
> >
> > I think the right way to say it is that if the GetHashCode result is
> > computed from values of one or more properties (or fields) of the
> object,
> > those values must be immutable -- either that, or special code needs
> to
> > exist to ensure that once GetHashCode() has returned a value, that
> object
> > instance must always return the same value from later GetHashCode
> calls.
> >
> > It seems to me that it would be perfectly acceptable to implement
> > GetHashCode so that the first time it's called, it computes, records,
> and
> > returns an at-least-somewhat random value (perhaps based on the
> current
> > value of one or more properties). On subsequent calls, the value
> returned
> > the first time is returned again (even if the values the initial
> > computation had been based on has changed). Is there a case where
> this
> > violates either the spirit or the letter of the GetHashCode contract?
> >
> > >> Other than the Hashtable and ProperytCollection classes, does
> > >> anyone know where GetHashCode() is used in the framework with
> > >> a collection of references?
> > >
> > > IMHO everywhere where Equals is used as well, as you have to
> > override GetHashCode as well if Equals is overriden. Equals is used in
> > IndexOf, Contains of ArrayList
> > >
> > > Frans
> >
> >
> > J. Merrill / Analytical Software Corp
> >
> > ===================================
> > This list is hosted by DevelopMentor(r) http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentor® http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com
>
Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
