Should null == null be true when comparing objects?

Question

I'm curious what everyone thinks. In SQL (at least in oracle) NULL translates conceptually to "I don't know the value" so NULL = NULL is false. (Maybe it actually results in a NULL which then gets cast to false or something like that...)

This makes sense to me, but in most OO languages null means "no reference" so null==null should probably be true. This is the usual way of doing things in C# for example when overriding Equals.

On the other hand, null is still frequently used to mean "I don't know" in object-oriented languages and implementing null==null to false might result in code that is slightly more meaningful to certain domains.

Tell me what you think.

Answer 1

I already get annoyed enough at the IEEE NaN not being equal to itself. I tend to view == as an equivalence relation, one of whose properties is reflexivity. If you have special semantics of "unknown" value equality, I think you should use something more specific rather than overloading an operator whose semantics are well understood. For example, just because you don't know if two values are equal, doesn't mean they definitely are not equal, which is what I'd guess from a False return value from ==. It seems like you really want some sort of ternary logic. Depending on your language, it may or may not be easy for you to come up with a concise ==-alike that can return True or False or NoClue, but I definitely think it should be separate.

Just my opinion on the matter though :)

Answer 2

I think that null in Java, just like NULL in C++ or None in Python, means specifically "there's nothing here" -- not "I don't know", which is a concept peculiar to SQL, not common in OOP languages.

Answer 3

For general purpose programming, null == null should probably return true.

I can't count the number of times I've run into the

if( obj != null )
{
   //call methods on obj
}

pattern, and it often seems unavoidable. If null == null evaluated to false, this pattern would fall apart, and there wouldn't be a good way to handle this case without exceptions.

Answer 4

First null == null being true makes patterns like

if(!(instance == null)) {
    // do something requiring instance not be null
}

work. (Yes, the usual test is instance != null but I want to make clear the use of !(null == null) being false.)

Second, if you need instance1 == instance2 to be false when instance1 and instance2 are null reference instances of your class, then this should be encapsulated into a logic class somewhere. In C#, we would say

class MyObjectComparer : IEqulityComparer<MyObject> {
    public bool Equals(MyObject instance1, MyObject instances2) {
        if(instance1 == null && instance2 == null) { 
            return false;
        }
        // logic here
    }

    public int GetHashCode(MyObject instance) {
        // logic here
    }
}

Answer 5

All null pointers (or references) are equal to each other.

They have to be, otherwise how would you compare a null pointer tonull?

Answer 6

If you said null === null, I would agree with you.

Answer 7

C++: comparing null pointers always returns true. If somehow you have a null reference (don't do that) the result is crash.

Answer 8

In my opinion the current behavior is correct, especially if you consider that null is interpreted as "Unknown value".

Think about it this way: If someone asked you whether the number of apples inside two boxes that you didn't know the contents of were equal. The answer wouldn't be yes or no, it would be "I don't know."

Answer 9

I think you've got your basic facts about SQL completely wrong.

NULL is a data value and UNKNOWN is a logical value.

NULL = NULL is UNKNOWN.

NULL = NULL is certainly not FALSE!

Google for "three value logic".

The NULL value is the placeholder for a missing data value. Ideally, a NULL-able column should only be used for values that are only temporarily missing i.e. there's a reasonable expectation that a non-NULL value will be available in the future e.g. using the NULL value for the end date in a pair of DATETIME values used to model a period to signify infinity i.e. this period is current (though a far-future DATEITME value works well too).