| Oliver Wong 2006-03-09, 6:55 pm |
| "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:47b5eeFef0qkU1@individual.net...
>
> I understand the reasoning behind '==' comparing the references. I just
> don't agree with it. Meaning, I think to most people just starting
> programming, with little understanding of a "reference object" versus a
> primative type, would assume that "if (string1 == string2)" would be
> comparing the "values" of the strings, and whether or not the two strings
> refer to the same object. Personally, I'd treat == of two objects as an
> alias for the "equals" method and have something else be used for a
> reference comparison. Perhaps "if (@string1 == @string2)" or something...
>
>
> As a matter of fact, this is pretty much how C# works
> if (s1 == s2): compares the values of the two strings
>
> if ((object) s1 == (object) s2): compares the "references" of the two
> strings
>
> Not sure if this is true only for strings or for all objects...
C# implements comparing the contents of strings via operator
overloading. That is, in C#, you as, a programmer, can change the behaviour
of the "==" operator. I suspect that the default behaviour of the ==
operator in C# is to compare references, but the person who wrote the String
class overrode the operator to instead compare the contents of the string.
One problem with this is that it's not always clear, for two given
objects, whether they should be considered equal; rather, it depends a lot
on context. With strings, for example, it's common to want to perform a
case-insensitive comparison. You might claim that it's trivial to implement
your own version of case-insensitive comparison by simply converting both
strings to uppercase first, then doing the comparison.
The problem with this, however, is that it's not always clear what the
uppercase of a given character is. The German character with Unicode
Codepoint \u00DF is considered a "lowercase" character. When converted to
uppercase, it sometimes becomes "SS", and other times becomes "SZ".
That means, for example, if you want to do a case-insentive comparison
between "\u00DF\u00DF" and "SSSZ", you can't simply convert the first string
to uppercase and then doing the comparison, as the transformation to
uppercase migth result in "SSSS", and then the comparison would return
false, as "SSSS" != "SSSZ", whereas "SSSZ" is indeed equal to "\u00DF\u00DF"
in a case-insensitive comparison.
This problem isn't limited only to Strings... For any kind of objects,
there might be multiple definitions of "equality", depending on the context.
Are two files considered "equal" if their contents are the same, but their
last-modified timestamps differ? Is the value 5.0 considered "equal" to 5.00
(was the extra zero an indication of more significant digits due to more
accurate measurement, or just a whim of the user entering the data)? Etc.
Java sort of has a solution to this problem. They have an class called a
Comparator, which is I guess sort of like COLLATING SEQUENCEs in COBOL,
where you can define the exact behaviour for whether objects are less than,
equal, or greater than each other. You could have the exact same set of
objects (e.g. a bunch of files), and have two Comparators acting on them, so
that sometimes the timestamp matters, and sometimes it doesn't, depending on
the context.
The only problem with Comparators is that it enforces a total ordering
on the objects. That is, for every pair of objects of the same type, the
comparator must either say "Less than", "Equal to" or "Greater Than".
Because the objects must be of the same type, you don't have to worry about
comparing numbers to files for example. But it does mean that you cannot
simply say an Apple is "Not Equal" to an Orange; instead, you'd have to
actually specify one of them as being "less than" the other.
- Oliver
|