"==" not symmetric

[Unknown W. Brackets]

Bad means a pointer to an invalid object.  A bad pointer.  I was trying 
to cover all the bases.

Your typical opEquals looks like this:

bool opEquals(Object o)
{
    Foo f = cast(Foo) o;

    // If o was null, or if f is now null (doesn't match class) fail.
    if (f is null)
       return false;

    return f.prop == this.prop;
}

Anything else either doesn't work properly with subclassing, isn't 
typesafe, or will segfault.  This doesn't seem wrong to me.

Okay, missed that x and y were supposed to be objects.  You seem to be 
missing a "x y" case, then.  This would be the same as "y x", though.

It would be a bad idea to check the class info imho.  Why can't a XYZ 
equal an ABC even if they share no parents aside from Object?  But that 
does mean the order of the comparison does matter (consider Array == 
SpecializedArray vs. SpecializedArray == Array.)

No, opEquals should never begin with any check on lhs... lhs will be 
this.  It should however check rhs, first casting it more than likely, 
and then checking for null on the cast.... since, if the cast fails, it 
will be null.

This same check cannot be necesarily made in ==, since it can't know 
what other classes the opEquals supports.

Still, checking for null could be a good thing for sanity; I'd guess it 
doesn't because opEquals would have to anyway.

-[Unknown]


> 'bad'? I don't think you can tell whether a pointer is bad or valid. I think 
> calling opEquals(null) is bad, since it's likely to crash. And I've noticed 
> before that many implementations start with a if(lhs is null) check. It just 
> makes sense to put that check 1 function up in the code, namely in the ==.
> 
>> I don't know what "y" is on your table.
> 
> 'y' is just different from 'x' :)
> 
> 
> Might not be a bad idea to also check the classinfo of both objects in the 
> == ?
> 
>> So, okay... the only differences we have:
>>
>> If o1 is null, reversing the comparison will depend on opEquals returning 
>> false when it is passed a null pointer (which should be the case.)
> 
> Right. At the moment opEquals _must_ begin with "if (lhs is null) return 
> false;", but this can easily be enforced by putting the same check in ==.
> 
>> Comparing a valid pointer to a bad pointer cannot be properly reversed, or 
>> it might cause a segfault.  This is always wrong anyway imho.
> 
> Right. Nothing you can do about that I'm afraid.
> 
>> That said, opEquals (imho) will either always check for null or cannot be 
>> reversed (null == evaluatesToNullObject is always false.)  So it would 
>> seem logical to do something like you suggested.
> 
> It would seem so :)