Brendan Tompkins [MVP]

Sam,

This very thought was occuring to me as I was posting this. Others were, 1) no one cares anyhow, and 2) why don't I just delete the old posts? and 3) I really should have stuck with my original career plan of owning a falafel cart.

But yes. I agree.

The long and short of it, with the Overloading and Equality post, is that I was describing how to create a hash code based on settable members. As Raymond Chen put it in a comment (I should frame that one) is that you should only override hash code if your obeject's hash code is never going to change throughout the life of the object. I was letting the value change, so I violated this rule.

I'm not sure exactly what to do about object equality now. What I've been doing lately is ignoring it all together in favor of comparing some key value if I need to test for that kind of equality.

-Brendan

We all "evolve" over time Brenden. I constantly find things in my old code that make me roll my eyes.

That behaviour comes from overriding .GetHashCode() though right? I know the compiler warns you to override .GetHashCode() when you override .Equals(object,object), but could you enlighten me about why:

override GetHashCode() { base.GetHashCode(); }

Doesn't suffice? You can still override .Equals() and the operators you want, and just not mess with .GetHashCode then no? Yes?

Hi Sam,

Good question, although I think the intent of the compiler warning is that if you change what equals means, you should change your hash codes too. It's kind of a catch 22, because then anything you're using to determine equality can't change in the lifetime of your object.

So say you have the following object:

[AirCode]
public class Person ()
{
public string FirstName;
public string LastName;

override bool Equals(object o)
{
return (o != null && o is Person && (Person)o.FirstName == this.FirstName && (Person)o.LastName == this.LastName);

}

override int GetHashCode()
{
return base.GetHashCode();
}
}

[AirCode, Test]
public void TestEquality()
{
Person person1 = new Person();
person1.FirstName = "Sam";
person1.LastName = "Coder";

Person person2 = new Person();
person2.FirstName = "Sam";
person2.LastName = "Coder";

if(person1.Equals(person2))
Trace.WriteLine("They're equal!");

ArrayList al = new ArrayList();
al.Add(person1);

if(al.Contains(person2))
Trace.WriteLine("Don't add Sam Again");
else
al.Add(person2);
}

If you actually did this, you'd end up with two Person Objects in your ArrayList both "Equal", since their hash codes are different. This wouldn't be what you would want, right? So to fix this, you'd override GetHashCode() to do somethign like this:

override int GetHashCode()
{
return this.FirstName.GetHashCode() ^ this.LastName.GetHashCode();
}

But if you did this, you could never let a person's first or last name change, in the lifetime of an object. This may be okay for a person, but could be limiting in other situations.

Perhaps this will generate some more discussion on this. I'm not 100% clear, like I said before.

Oooooooh. Ok, thanks for clearing that up for me.

That looks nice, but why a pink box?

That's not pink dammit! It's light puce!