Peter Morris [Droopy eyes software] wrote:
I'm not impressed at all to be honest. To implement "Equals" I have to do
two things?
1) Implement Equals
2) Override ==
No. To implement Equals, you just have to implement Equals.
If you want to make it so that clients get value equality from ==
rather than reference equality, you also need to overload (not
override) ==. They're different things, and it often makes sense to do
one but not the other.
I really don't like it. Two things are either equal or they are not.
No - two references are either unrelated, refer to equal objects, or
refer to the same object.
It makes no sense to say A equals B but B does not equal A, and along these
lines I therefore state that A == B should always return the same as
A.Equals(B)
The problem is that A and B are references. A.Equals(B) is asking
whether the objects referred to by A and B are equal. A==B is (usually)
asking whether A and B are equal *in themselves*.
At the moment it's a bit too much like a human response:
Question: Does A equal B?
Answer: It depends who you ask
Suppose I go to see a production of "Sunday in the Park with George" in
London. (I wish I had the time...) Now suppose a friend of mine sees a
production of "Sunday in the Park with George" in Broadway.
Did we see the same show? Well, sort of - it was the same musical, but
different productions. (You could take the analogy further - what about
if we both saw it in London, but on different nights?)
Whether you like the behaviour or not, that *is* the behaviour of
C#/.NET.
Jon