¿Debe null == null ser verdadero al comparar objetos?

Question

Tengo curiosidad por lo que todos piensan. En SQL (al menos en Oracle) NULL se traduce conceptualmente a "No sé el valor", por lo que NULL = NULL es falso. (Tal vez realmente da como resultado un NULO que luego se convierte en falso o algo así ...)

Esto tiene sentido para mí, pero en la mayoría de los lenguajes de OO null significa "sin referencia", por lo que nulo == nulo probablemente ser cierto. Esta es la forma habitual de hacer las cosas en C#, por ejemplo, al anular Iguales.

Por otro lado, null todavía se usa con frecuencia para significar "No sé" en lenguajes orientados a objetos y la implementación de null == null como falso podría dar como resultado un código que es ligeramente más significativo para ciertos dominios.

Dime lo que piensas.

Answer 1

Ya me enojo lo suficiente en el IEEE NaN al no ser igual a sí mismo. Tiendo a ver == como una relación de equivalencia, una de cuyas propiedades es la reflexividad. Si tiene una semántica especial de igualdad de valores "desconocidos", creo que debería usar algo más específico en lugar de sobrecargar a un operador cuya semántica es bien comprendida. Por ejemplo, el hecho de que no sepas si dos valores son iguales no significa que definitivamente no sean iguales, que es lo que supongo de un valor de retorno falso de ==. Parece que realmente quieres algún tipo de lógica ternaria. Dependiendo de su idioma, puede o no puede ser fácil para usted encontrar un conciso == - que pueda devolver verdadero o falso o NoClue, pero definitivamente creo que debería estar separado.

Sólo mi opinión sobre el asunto aunque :)

Answer 2

creo que nula en Java, al igual que NULL en C++ o Nada en Python, significa específicamente "no hay nada aquí" - no "I don' t know ", que es un concepto peculiar de SQL, no es común en los lenguajes de OOP.

Answer 3

Para programación de propósito general, null == null probablemente debería ser verdadero.

No puedo contar el número de veces que me he encontrado con el patrón

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

, y que a menudo parece inevitable. Si null == null evaluado como falso, este patrón se derrumbaría, y no habría una buena manera de manejar este caso sin excepciones.

Answer 4

Primera null == null siendo true hace patrones como

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

trabajo. (Sí, la prueba usual es instance != null pero quiero dejar en claro el uso de !(null == null) siendo false.)

En segundo lugar, si necesita instance1 == instance2 ser falsa cuando instance1 y instance2 son ejemplos de referencia nulos de su clase, entonces esto debe ser encapsulado en una clase lógica en alguna parte. En C#, diríamos

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

Todos los punteros nulos (o referencias) son iguales entre sí.

tienen ser, de lo contrario, ¿cómo compararía un puntero nulo a null?

Answer 6

Si dijo null === null, estoy de acuerdo con usted.

Answer 7

C++: la comparación de punteros nulos siempre devuelve verdadero. Si de alguna manera tiene una referencia nula (no lo haga), el resultado es un bloqueo.

Answer 8

En mi opinión, el comportamiento actual es correcto, especialmente si se considera que null se interpreta como "Valor desconocido".

pensar de esta manera: Si alguien le preguntó si el número de manzanas dentro de dos cajas que usted no conoce el contenido del eran iguales. La respuesta no sería sí o no, sería "No sé".

Answer 9

Creo que tiene sus datos básicos sobre SQL completamente equivocados.

NULL es un valor de datos y UNKNOWN es un valor lógico.

NULL = NULL es UNKNOWN.

NULL = NULL ciertamente no es FALSE!

Google para "tres valores lógicos".

El valor NULL es el marcador de posición para un valor de datos faltante. Idealmente, una columna de NULL solo se debe usar para valores que solo faltan temporalmente, es decir, existe una expectativa razonable de que un valor que no sea NULL estará disponible en el futuro, p. utilizando el valor NULL para la fecha de finalización en un par de DATETIME valores utilizados para modelar un período para indicar infinito, es decir, este período es actual (aunque un valor futuro lejano DATEITME también funciona bien).