Should null == null be true when comparing objects?

Question

I'm curious what everyone thinks. In SQL (at least in oracle), NULL transforms conceptually into "I don't know the value", so NULL = NULL is false. (Maybe this actually leads to NULL, which is then passed 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 to do things in C #, for example, when overriding Equals.

On the other hand, null is still often used to mean “I don’t know” in object-oriented languages, and implementing null == null in false can cause the code to be somewhat more meaningful for certain domains.

Tell me what you think.

Answer 1

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

I can’t count the number of times I ran

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

and it often seems inevitable. If null == null evaluates to false, this pattern will fall apart, and there would be no good way to handle this case without exception.

Answer 2

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

Answer 3

I was already quite angry when IEEE NaN was not equal to myself. I am inclined to consider == as an equivalence relation, one of the properties of which is reflexivity. If you have special semantics of the “unknown” meaning of equality, I think you should use something more specific, rather than overloading an operator whose semantics are well understood. For example, just because you do not know if two values ​​are equal, this does not mean that they are definitely not equal, which I would suggest from the value False return from ==. It seems you really need some kind of triple logic. Depending on your language, it may be easy or hard for you to come up with a short == - similar one that can return True or False or NoClue, but I definitely think it should be separate.

Just my opinion on this issue :)

Answer 4

I think you have your basic facts that SQL is completely wrong.

NULL is the data value, and UNKNOWN is the boolean value.

NULL = NULL is UNKNOWN .

NULL = NULL , of course, not FALSE !

Google for "three-digit logic."

NULL is a placeholder for a missing data value. Ideally, the NULL -able column should only be used for values ​​that are temporarily missing, i.e. There is a reasonable expectation that a non- NULL value will be available in the future, for example. using the NULL value for the end date in a pair of DATETIME values ​​used to simulate a period to indicate infinity, i.e. this period is current (although the meaning of the distant future DATEITME also works well).

Answer 5

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

Answer 6

The first null == null , which is true , creates patterns such as

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

Job. (Yes, the regular test instance != null , but I want to make it clear to use !(null == null) false .)

Secondly, if you need instance1 == instance2 be false, if instance1 and instance2 are null reference instances of your class, then this should be encapsulated in some kind of logical class. 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 7

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

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

Answer 8

C ++: comparing null pointers always returns true. If you have a null reference (do not do this), the result will fail.

Answer 9

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

Think of it this way: If someone asked you whether the number of apples inside two boxes that you did not know was equal in content. The answer would be no yes or no, it would be I do not know.