"==" not symmetric

[Lionello Lunesu]

"Unknown W. Brackets" <unknown at simplemachines.org> wrote in message 
news:e50lr3$rqo$1 at digitaldaemon.com...
> o1     o2     result
> null   null   true
> null   valid  false
> null   bad    false
> valid  null   result of opEquals(null) - probably false
> valid  valid  result of opEquals(valid) - unknown result
> valid  bad    result of opEquals(bad) - probably false
> bad    null   segfault
> bad    valid  segfault
> bad    bad    segfault unless equal bad pointers, then true

'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' :)

> bool opEquals(Object o)
> {
>    return true;
> }
>
> Obviously, we have to assume that o1 and o2 are of the same type, or else 
> different opEquals might be called.

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 :)

L.