Comparing apples and oranges

[Stewart Gordon]

Jarrett Billingsley wrote:
> On Tue, Sep 29, 2009 at 11:17 AM, Denis Koroskin <2korden at gmail.com> wrote:
>> I believe Java and C# took bool Object.equals(Object other); way because
>> they lacked generics intially and stored all the instances as Objects in
>> containers (having equals method in Object allowed them proper ordering
>> etc).

I believe Java still does internally, and generics are just a coding 
convenience.

http://en.wikipedia.org/wiki/Generics_in_Java#Type_erasure

>> D doesn't suffer from that problem and doesn't have to follow the same way
>> those languages took.
> 
> I agree, opEquals and opCmp in Object feel like out-of-date relics.
> It's particularly annoying how, if you want your classes to behave
> with arrays/AAs, you must override opEquals(Object), meaning you have
> to do silly downcasts at runtime.

I've always been against opCmp being in Object.  opEquals being in 
Object is harder to dismiss, as I can imagine that someone might find a 
use case for being able to store an arbitrary mix of objects in a 
container and in doing so be able to compare them.

But I do wonder if Object.opEquals could work better.  Maybe make it so 
that, if a class C contains a method opEquals(C), and opEquals(Object) 
has not been explicitly overridden by the programmer anywhere up the 
hierarchy, then opEquals(Object) will be automagically overridden to 
call opEquals(C).

The only trouble is that I'm not sure how well this would work when 
interfaces are involved.

>> BTW, nowadays, they define IComparable<T> interface, which is a recommended
>> way to implement comparison functions.
<snip>

Both Java's Comparable and, AFAICMO, .NET's IComparable, are for 
ordering comparisons.  Equality comparison is built into Object in both 
cases.

Stewart.