That what Jon meant when he said that it depends on what you mean by
"equality", and there are numerous pitfalls here. For instance, there
are two version of Equals, one is static (in the Object class), the
other is an instance method of your own objects. It is customary to
never override the first (so that object.Equals(o1, o2) will always
tell you whether the object is indeed the same object - read : has the
same place in memory, and will be equivalent to ReferenceEquals for
reference types), and occasionaly override the second (often together
with the == operator) to accomodate for the case you're stating
(comparing surfaces of two circles).
Another pitfall : ReferenceEquals will always return false for value
types. i.e. :
int a = 5;
int b = a;
Console.WriteLine(object.ReferenceEquals(a,b));
...will yield "false", because of the boxing that occurs on value
types in the ReferenceEquals method.
The thing is, as you can see, "being equal" can have several meanings.
That's why I usually never override Equals or ==, but provide a method
with a stupid/evocative name like "Circle.AreSurfacesEqual(o1, o2)".
It has the advantage of removing the ambiguity you're talking about.
That's just me, though.
Yes, good stuff here, I've added this quote of yours to my library of
C# stuff that I keyword search.
Yes, but as you can still discriminate the rows through the table name/
number, there won't be any collisions, in the same way you know that a
dog called "Snoop" is different from a cat named "Snoop", even though
they have the same name, the same number of legs, eyes... It's handled
in exactly the same way as the filesystem, if you have two files with
identical names in an identical directory structure, like this :
C:\Docs\SomeFolder\File1.txt
D:\Docs\SomeFolder\File1.txt
...you still know they're different files, because the full path
differs (even if only on one drive letter). if the *full* path was the
same, then it would be the same file. It's the same principle for DBs
and for memory management of variables.
Yes, sorry, my example was bad since it was not a true collision. But
my point is that unless you use GUIDs or Autoincrement or some such
number as your Primary key, it's hard to define uniqueness. However,
more relevant to C#, after going through this thread I feel better
that C# does indeed distinquish between data (variables, objects,
whatever) stored in different parts of memory for the .Equals method
and for ReferenceEquals (which I didn't even know existed as a method)
and doesn't rely on an internal number and/or hash number. And I
agree that overloading "=" or Equals or "+" operator as was the
fashion for C++ is just eye candy / syntatic sugar is not a good idea,
so I like your suggestion of Circle.AreSurfacesEqual.
RL
