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

Question

Мне любопытно, что все думают. В SQL (по крайней мере, в oracle) NULL трансформирует концептуально в «Я не знаю значения», поэтому NULL = NULL является ложным. (Может быть, это на самом деле приводит к NULL, который затем получает значение false или что-то в этом роде ...)

Это имеет смысл для меня, но в большинстве языков OO значение null означает «no reference», поэтому null == null должно, вероятно, будь настоящим. Это обычный способ делать вещи в C#, например, при переопределении Equals.

С другой стороны, значение null по-прежнему часто используется для обозначения «Я не знаю» в объектно-ориентированных языках, а реализация null == null в false может привести к тому, что код несколько более значим для определенных доменов.

Скажите, что вы думаете.

Answer 1

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

Просто мое мнение по этому вопросу, хотя :)

Answer 2

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

Answer 3

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

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

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

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

Answer 4

Первый null == null быть true делает модели как

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

Answer 9

Я думаю, что у вас есть свои основные факты о том, что SQL совершенно неверен.

NULL - значение данных, а UNKNOWN - логическое значение.

NULL = NULL является UNKNOWN.

NULL = NULL, конечно, не FALSE!

Google для «трехзначной логики».

Значение NULL является заполнителем для отсутствующего значения данных. В идеале, столбец NULL -able должен использоваться только для значений, которые временно отсутствуют, т. Е. Существует разумное ожидание того, что в будущем будет доступно значение не NULL, например. используя значение NULL для даты окончания в паре значений DATETIME, используемых для моделирования периода для обозначения бесконечности, то есть этот период является текущим (хотя значение далекого будущего DATEITME тоже хорошо работает).