views:

281

answers:

9

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.

+2  A: 

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

pumpkin
Thats true, "I don't know"=="I don't know" should result in "I don't know", not false - though converting from "I don't know" to false implicitly seems ok.
George Mauer
I think you mean `True`, `False`, or `FileNotFound` ;)
Mike Spross
+8  A: 

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.

Alex Martelli
I agree. In code, we often KNOW we have or get null - nothing. The state is finite and predictable.
Stefan Kendall
+8  A: 

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.

Stefan Kendall
In SQL there's a special operator for that called 'is'. So to test if something is NULL you use 'is NULL'. That is also the common practice in Python, although == also works.
gooli
Similarly, in VB.NET you have: `Is Nothing`
Rob Sobers
+1  A: 

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
    }
}
Jason
A: 

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

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

Loadmaster
Well in C# at least the correct way of doing null checks is object.ReferenceEquals(null, variable)
George Mauer
Is this better (or different) than `p == null`?
Loadmaster
+2  A: 

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

Sasha
Hmm, thats a good point actually. A really really good point.
George Mauer
A: 

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

Joshua
A: 

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."

JohnFx
Exactly, and that's the way NULL in SQL works, there is just an implicit cast between NULL and false
George Mauer
+2  A: 

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

onedaywhen
I am not a SQL guy so that is totally possible. I work mostly with oracle and in oracle NULL + anything = NULL and SELECT 1 from DUAL WHERE NULL=NULL returns 0 rows. I have read that this is because "I don't know" is the conceptual definition of null.
George Mauer
In your defence, I think it is true that Oracle does not implement NULL correctly. IIRC, '' [empty string] IS NULL is TRUE for Oracle, whereas in SQL it is FALSE. Note that NULL is treated differently for SQL DDL e.g. a row-level CHECK constraint that evaluates to NULL allows the update to succeed, a kind of 'benefit of the doubt' effect.
onedaywhen