Должен аннулировать == пустой указатель быть верным при сравнении объектов?

Для программирования общего назначения null == null, вероятно, должно возвращать истину.

Я не могу сосчитать, сколько раз я встречался с шаблоном

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

, и это часто кажется неизбежным. Если null == null оценивается как false, этот шаблон развалится, и не было бы хорошего способа справиться с этим случаем без исключений.

Я думаю, что null в Java, так же, как NULL в C ++ или None в Python, конкретно означает «здесь ничего нет» - не «Я не знаю» , которая является концепцией, свойственной SQL, не распространенной в языках ООП.

Меня уже достаточно раздражает то, что IEEE NaN не равен самому себе. Я склонен рассматривать == как отношение эквивалентности, одним из свойств которого является рефлексивность. Если у вас есть особая семантика «неизвестного» равенства значений, я думаю, вам следует использовать что-то более конкретное, а не перегружать оператор, семантика которого хорошо изучена. Например, то, что вы не знаете, равны ли два значения, не означает, что они определенно не равны, что я бы предположил, исходя из значения, возвращаемого False из ==. Похоже, вам действительно нужна какая-то троичная логика. В зависимости от вашего языка вам может быть непросто придумать лаконичный == - подобный, который может возвращать True, False или NoClue, но я определенно думаю, что это должно быть отдельно.

Просто мое мнение о хотя :)

Если бы вы сказали null === null , я бы с вами согласился.

Первый null == null , будучи истинным , заставляет работать такие шаблоны, как

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

. (Да, обычный тест - instance! = Null , но я хочу прояснить, что использование ! (Null == null) является false .)

Во-вторых, если вам нужно, чтобы instance1 == instance2 было ложным, когда instance1 и instance2 являются экземплярами нулевой ссылки вашего класса, то это должно быть инкапсулировано в логический класс где-нибудь. В C # мы бы сказали

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
    }
}

Все нулевые указатели (или ссылки) равны друг другу.

У них должно быть , иначе как бы вы сравнили нулевой указатель с нулевым ?

C ++: сравнение нулевых указателей всегда возвращает истину. Если каким-то образом у вас есть пустая ссылка (не делайте этого), результатом будет сбой.

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

На мой взгляд, текущее поведение является правильным, особенно если учесть, что null интерпретируется как «Неизвестное значение».

Подумайте об этом так: Если кто-то спросит вас, одинаково ли количество яблок в двух коробках, о которых вы не знали. Ответом будет не «да» или «нет», это будет «не знаю».