Jarrett Billingsley wrote:
On Tue, Sep 29, 2009 at 11:17 AM, Denis Koroskin <2kor...@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.
