Il valore null == null è vero quando si confrontano gli oggetti?

Question

Sono curioso di sapere cosa pensano tutti. In SQL (almeno in oracle) NULL traduce concettualmente in "Non conosco il valore", quindi NULL = NULL è falso. (Forse in realtà risulta in un NULL che poi viene castato in falso o qualcosa del genere ...)

Questo ha senso per me, ma nella maggior parte dei linguaggi OO null significa "nessun riferimento" quindi null == null dovrebbe probabilmente essere vero. Questo è il solito modo di fare cose in C#, ad esempio quando si esegue l'override di Equals.

D'altra parte, null è ancora utilizzato frequentemente per significare "Non so" in linguaggi orientati agli oggetti e l'implementazione di null == null su false potrebbe comportare un codice leggermente più significativo per determinati domini.

Dimmi cosa ne pensi.

Answer 1

Sono già abbastanza infastidito dal fatto che IEEE NaN non sia uguale a se stesso. Tendo a visualizzare == come una relazione di equivalenza, una delle cui proprietà è la riflessività. Se hai una semantica speciale di uguaglianza del valore "sconosciuto", penso che dovresti usare qualcosa di più specifico piuttosto che sovraccaricare un operatore la cui semantica è ben compresa. Ad esempio, solo perché non sai se due valori sono uguali, non significa che sicuramente non sono uguali, che è quello che immagino da un valore di ritorno False da ==. Sembra che tu voglia davvero una sorta di logica ternaria. A seconda della tua lingua, potrebbe essere semplice o meno per te trovare un conciso == - allo stesso modo che può restituire True o False o NoClue, ma penso che debba essere separato.

Appena il mio parere sulla questione però :)

Answer 2

penso che nulla in Java, proprio come NULL in C++ o None in Python, significa in particolare "qui non c'è niente" - non "I don' t know ", che è un concetto peculiare di SQL, non comune nei linguaggi OOP.

Answer 3

Per la programmazione generica, null == null dovrebbe probabilmente restituire true.

Non riesco a contare il numero di volte che ho incontrato il modello

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

, e sembra spesso inevitabile. Se null == null è stato valutato come falso, questo modello andrebbe a pezzi e non ci sarebbe un buon modo per gestire questo caso senza eccezioni.

Answer 4

Prima null == null essere true rende modelli come

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

lavoro. (Sì, la solita prova è instance != null ma voglio mettere in chiaro l'uso di !(null == null) essere false.)

In secondo luogo, se è necessario instance1 == instance2 di essere falsa quando instance1 e instance2 sono casi riferimento null della vostra classe, allora questo dovrebbe essere incapsulato in una classe logica da qualche parte. In C#, diremmo

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

Tutti i puntatori nulli (o riferimenti) sono uguali tra loro.

Essi hanno essere, altrimenti come si confronta un puntatore nullo a null?

Answer 6

Se hai detto null === null, sarei d'accordo con te.

Answer 7

C++: il confronto dei puntatori nulli restituisce sempre true. Se in qualche modo hai un riferimento null (non farlo) il risultato è crash.

Answer 8

A mio parere il comportamento corrente è corretto, soprattutto se si considera che null viene interpretato come "Valore sconosciuto".

pensare in questo modo: Se qualcuno ti ha chiesto se il numero di mele all'interno di due scatole che non sapevi il contenuto di fosse uguale. La risposta non sarebbe sì o no, sarebbe "non lo so".

Answer 9

Penso che tu abbia i tuoi dati di base su SQL completamente sbagliato.

NULL è un valore di dati e UNKNOWN è un valore logico.

NULL = NULL è UNKNOWN.

NULL = NULL non è certamente FALSE!

Google per "logica a tre valori".

Il valore NULL è il segnaposto per un valore di dati mancante. Idealmente, una colonna di tipo NULL deve essere utilizzata solo per valori che mancano solo temporaneamente, quindi c'è una ragionevole aspettativa che un valore non NULL sarà disponibile in futuro, ad es. utilizzando il valore NULL per la data di fine in una coppia di valori DATETIME utilizzati per modellare un periodo per indicare l'infinito, vale a dire che questo periodo è corrente (anche se un valore di futuro DATEITME funziona bene).