Perché c'è un valore "null" in JavaScript?

In JavaScript, ci sono due valori che sostanzialmente dicono "Non esisto" - undefinede null.

Una proprietà a cui un programmatore non ha assegnato nulla sarà undefined, ma affinché una proprietà lo diventi null, nulldeve essere assegnata esplicitamente ad essa.

Una volta ho pensato che fosse necessario nullperché undefinedè un valore primitivo e nullun oggetto. Non lo è, anche se typeof nullprodurrà 'object': in realtà, entrambi sono valori primitivi, il che significa che né undefinedné nullpossono essere restituiti da una funzione di costruzione, poiché entrambi verranno convertiti in un oggetto vuoto (si deve lanciare un errore per proclamare il fallimento nei costruttori).

Entrambi valutano anche falsein contesti booleani. L'unica vera differenza a cui riesco a pensare è che uno valuta a NaN, l'altro a 0in contesti numerici.

Allora perché ci sono entrambi undefinede nullse questo confonde solo i programmatori che stanno controllando in modo errato nullquando cercano di scoprire se una proprietà è stata impostata o meno?

Quello che vorrei sapere è se qualcuno ha un esempio ragionevole in cui è necessario usare nullche non potrebbe essere espresso usando undefinedinvece.

Quindi il consenso generale sembra essere che undefinedsignifica "non esiste tale proprietà" mentre nullsignifica "la proprietà esiste, ma non ha valore".

Potrei conviverci se le implementazioni JavaScript impongono effettivamente questo comportamento, ma undefinedè un valore primitivo perfettamente valido, quindi può essere facilmente assegnato alle proprietà esistenti per rompere questo contratto. Pertanto, se vuoi assicurarti che una proprietà esista, devi usare l' inoperatore o hasOwnProperty()comunque. Quindi ancora una volta: qual è l'uso pratico di valori separati per undefinede null?

In realtà lo uso undefinedquando voglio annullare l'impostazione dei valori delle proprietà non più in uso ma che non voglio delete. Dovrei usare nullinvece?

La domanda non è realmente "perché c'è un valore nullo in JS" - c'è un valore nullo di qualche tipo nella maggior parte delle lingue ed è generalmente considerato molto utile.

La domanda è: "perché c'è un valore indefinito in JS". Luoghi principali in cui viene utilizzato:

1. quando si dichiara var x;ma non si assegna ad esso, xvale indefinito;
2. quando la tua funzione ottiene meno argomenti di quelli che dichiara;
3. quando si accede a una proprietà dell'oggetto inesistente.

nullavrebbe sicuramente funzionato altrettanto bene per (1) e (2) *. (3) dovrebbe davvero lanciare subito un'eccezione, e il fatto che non lo faccia, invece di restituire questo strano undefinedche fallirà in seguito, è una grande fonte di difficoltà di debug.

*: potresti anche sostenere che (2) dovrebbe generare un'eccezione, ma poi dovresti fornire un meccanismo migliore e più esplicito per argomenti predefiniti / variabili.

Tuttavia JavaScript non aveva originariamente eccezioni o alcun modo per chiedere a un oggetto se avesse un membro con un certo nome: l'unico modo era (e talvolta lo è ancora) accedere al membro e vedere cosa ottieni. Dato che nullaveva già uno scopo e potresti volerlo impostare un membro, era richiesto un valore diverso fuori banda. Quindi abbiamo undefined, è problematico come fai notare, ed è un'altra grande "funzionalità" di JavaScript di cui non saremo mai in grado di sbarazzarci.

In realtà utilizzo undefined quando desidero annullare l'impostazione dei valori di proprietà non più in uso ma che non voglio eliminare. Dovrei invece usare null?

Sì. Mantieni undefinedcome valore speciale per segnalare quando altre lingue potrebbero generare un'eccezione.

nullè generalmente migliore, tranne su alcune interfacce DOM IE dove l'impostazione di qualcosa nullpuò darti un errore. Spesso in questo caso l'impostazione sulla stringa vuota tende a funzionare.

Meglio descritto qui , ma in sintesi:

undefined è la mancanza di un tipo e di un valore e null è la mancanza di un valore.

Inoltre, se stai facendo semplici confronti "==", hai ragione, vengono fuori lo stesso. Ma prova ===, che confronta sia il tipo che il valore, e noterai la differenza.

Non credo che ci sia alcun motivo per avere entrambi nulle undefined, poiché l'unica ragione per cui molte persone hanno suggerito (" undefinedsignifica che non esiste una tale variabile / proprietà") non è valida, almeno in JavaScript. undefinednon può dirti se la variabile / proprietà esiste o meno.

console.log(foo);               // "ReferenceError: foo is not defined"
                                // foo does not exist
var foo;
console.log(foo);               // "undefined", a different response
console.log(foo === undefined); // "true", but it does exist

var obj = {};
console.log(obj.hasOwnProperty("foo")); // "false", no such property
obj.foo = undefined;
console.log(obj.hasOwnProperty("foo")); // "true", it exists and has the value "undefined"
console.log(obj.foo === undefined);     // "true", but it does exist

obj.bar = "delete me";
obj.bar = undefined;
console.log(obj.hasOwnProperty("bar")); // "true", not actually deleted
delete obj.bar;
console.log(obj.hasOwnProperty("bar")); // "false", deleted

Come puoi vedere, il controllo foo === undefinednon ti dice se fooesiste e l'impostazione obj.bar = undefinednon viene effettivamente eliminata bar.

Potrebbe essere l'intento originale dell'autore di JavaScript che undefineddovrebbe rappresentare la "non esistenza". Tuttavia, l'implementazione non è andata in questo modo.

È del tutto possibile aver bisogno di entrambi. Ad esempio, se si esegue una query su WMI, è del tutto possibile avere proprietà di ritorno di una classe che hanno un valore nullo. Sono definiti, capita che siano nulli al momento.

Penso che la tua conclusione che JavaScript definisce undefinedcome "non esiste tale proprietà" enull come "la proprietà non ha valore" sia perfettamente corretta. E in un linguaggio dinamico come JavaScript è una distinzione molto importante. L'uso della dattilografia significa che dobbiamo essere in grado di distinguere tra una proprietà che non esiste e che non ha un valore. È il nostro mezzo principale per ricavare informazioni sul tipo. in un linguaggio tipizzato staticamente esiste una netta distinzione tra un campo nullo e un campo non esistente. In JavaScript questo non è diverso. Tuttavia è controllato in fase di esecuzione e può essere modificato fino a quel momento.

Devo ammettere che l'implementazione è strana poiché molte volte la distinzione è offuscata. Tuttavia penso che in JavaScript la distinzione sia importante. E poter assegnareundefined è essenziale.

Ricordo di aver letto un post sul blog qualche tempo fa su un gioco di ruolo online scritto in JavaScript. Ha utilizzato esempi in cui gli oggetti sono stati creati come copie di istanze esistenti piuttosto che prototipi (classi, funzioni, qualsiasi cosa) e sono stati quindi modificati. Questo mi ha fatto davvero capire quanto undefinedpotesse essere potente quando si modificano oggetti esistenti, ma non ricordo chi l'abbia scritto.

Semanticamente significano cose diverse. Il tipo null ha esattamente un valore nel suo dominio, null e a una proprietà può essere assegnato questo valore specifico. Undefined rappresenta una netta mancanza di valore assegnato.

Come programmatore Java, vedo un'enorme differenza tra undefined e null. Codificare JavaScript, non tanto, perché JavaScript non è fortemente tipizzato e le differenze tra undefined e null sono offuscate dalle conversioni automatiche che vengono eseguite frequentemente in fase di esecuzione. A proposito, approfitto spesso di queste conversioni; rendono il mio codice JS più compatto e leggibile.

Per rispondere alla tua domanda, undefined significa che un valore non è mai stato impostato. In pratica, questo generalmente indica un bug. Se yourObject.property non è definito, significa che non hai impostato la proprietà per qualche motivo o sto cercando qualcosa che non esiste affatto. Questo è un vero problema quando si lavora su un progetto con più di un codificatore.

null significa che "nessun valore" è stato impostato esplicitamente. In pratica, mi stai dicendo qualcosa sulla proprietà, forse che non è utilizzata in questo contesto, o che un valore deve ancora essere determinato.

In Java, i tentativi di accedere a un campo non definito genereranno sempre un'eccezione. In effetti, il compilatore può essere creato per avvisarti di questo nel tuo codice.

Prova questo esempio:

<html>
<head>
    <script type="text/javascript">
        function ShowObjProperties(obj) {
            var property, propCollection = "";

            for(property in obj) {
                propCollection += (property + ": " + obj[property] + "\n");
            }

            alert(propCollection);
        }

        var obj = {
            userid: 3,
            name: 'me!',
            speak: function() { alert('Hi! My name is ' + this.name + ' and my ID is ' + this.userid + '.'); }
        }

        //Shows all properties
        ShowObjProperties(obj);

        //The Speak function is no longer in the list!
        delete obj.speak;
        alert(typeof obj.speak);
        ShowObjProperties(obj);

        //The UserID is still listed, it just has no value!
        obj.userid = null;
        ShowObjProperties(obj);
    </script>
</head>
<body>

</body>
</html>

Penso che qui ci sia un uso molto reale per 2 tipi diversi.

Ciò che ne consegue è la natura dinamica di javascript.

Le cose potrebbero non essere definite in modo che possano essere aggiunte in un secondo momento. Questo è probabilmente il motivo per cui javascript è così potente ed estensibile.

è una caratteristica del linguaggio importante se avvolgi il tuo programma attorno al paradigma con eventi di javascript.

// a key exists as a placeholder for something
if(obj[name] === null) 
// no key exists int eh hashtable that is in this object
if(obj[name] === undefined)

questo è molto utile se hai a che fare con un insieme di dati che necessita di un valore per rappresentare "niente" per indicare un'azione diversa dall'uso di "niente" per indicare l'azione predefinita.

filter_func_pt = {
  date:function(d){ return Math.round(d.getTime()/1000);},
  user: null,
}

function transform(obj){
    var ret = {};
    for( var prop in obj){
       var f = filter_func_pt[prop];
       if(f)
          ret[prop] = f(obj);
       else if(filter_func_pt[prop] === null)
         continue;
       else
         ret[prop] == obj;
    }
  return ret;
}

var a = {
   date: new Date(),
   user: 'sam'
   votes: [23, 41, 55] 
};

var b = transform(a);

/* b = {
 *    date: 1298582417
 *    votes: [23, 41, 55]
 * }
 */

nel codice sopra la parola chiave null e il server undefined scopi molto chiari e diversi. la ricerca che non si trova nell'oggetto filter_func_pt che restituisce undefined significa aggiungere la proprietà all'oggetto restituito così com'è, mentre un valore nullo indica che il valore deve essere trattenuto, e non aggiunto, e la presenza di qualsiasi valore vero in questo case rappresenta una funzione utilizzata per trasformare il valore prima di aggiungerlo all'oggetto ret .

null è bello

come tutti gli altri tipi di Live Script.

cite: In JavaScript, ci sono due valori che fondamentalmente dicono "Io non esisto": undefined e null.

Perché vorresti dire cose sbagliate ?!

"null" è "oggetto vuoto" proprio come "0" è un "numero vuoto" . 0, non è nulla, ma esiste come oggetto Tipo di numero. Ovviamente anche null è vuoto ma "lo è" ed è una cosa ben definita di un tipo di oggetto .

È comune parlare di queste cose come di "tipi", quando non lo sono. In realtà sono "categorie". Ma adesso è finita.

Quindi continuerò a dire che "null" è un tipo di oggetto senza un tipo. E "null" dice "io esisto [!], Ma non ho contenuti della mia specie".

Considerando che undefined manca sia del Type che del Kind, dove undefined è anche la sua definizione di Type. Un tipo indefinito di un tipo diventa la sua tipologia distintiva. Una sorta di domanda [non esiste "niente" e come definisci "niente"?].

cite: undefined né null possono essere restituiti da una funzione di costruzione, poiché entrambi saranno convertitori in un oggetto vuoto

Sei riuscito a dire ancora una volta una cosa sbagliata. Ovviamente no, l '"indefinito" non è un Oggetto, è un semplice Segno che noi umani comprendiamo; ma contrariamente a quel null è - e ti sta dicendo che: il suo Tipo è corretto, ma il Tipo che stai cercando non è contenuto al suo interno, o almeno - non in questo momento. Vieni a trovarci più tardi, quando inseriremo \ assegna qualche oggetto \ ad esso.

cita: L'unica vera differenza a cui riesco a pensare è che uno valuta NaN, l'altro 0 in contesti numerici.

Ciò rende l'intero punto della loro distinzione principale, come accennato: undefined è un semplice segno e poiché è costituito dallo stesso materiale 'genetico' dei suoi lontani parenti: stringhe, l'operazione [+ undefined] lo convertirà in anatra NaN, allo stesso modo null ovviamente si trasformerà in un tipo corretto 0 \ Number, e al contrario di undefined che si trasformerà in una stringa (! Che non è vuota!) Ed è esattamente per questo che restituisce NaN . Dove: + undefined >> + "undefined" >> NaN. Poiché il contesto numerico si aspetta un valore esplicito.

Mentre il contesto booleano si aspetta un riferimento, non trova nulla da convertire e restituisce "falso".

Tagliamo adesso ...

cite: Quindi ancora una volta: qual è l'uso pratico di valori separati per undefined e null?

Cercherò di darvi solo due esempi empirici e spero di bastare

oElement.onclick >> null

// significa che la proprietà esiste; il suo valore atteso è di Type: Object e che oElement supporta l'evento "onclick"!

oElement.innerText >> ""

// significa - la proprietà esiste; il suo valore atteso è di Tipo: String , il che significa che oElement supporta la proprietà "innerText".

in entrambi i casi -se ricevi "undefined" significa che la proprietà non esiste; non è supportato o ha un'implementazione sbagliata (ua vendor).

Resta al gelo e divertiti.

dopo aver letto un'incredibile discussione su undefined vs null, una piccola ricerca su Google mi ha portato a Mozilla Documentations https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/null è menzionato - null è spesso recuperato in un luogo in cui ci si può aspettare un oggetto ma nessun oggetto è rilevante.

Non è simile al pattern oggetto Null https://en.wikipedia.org/wiki/Null_object_pattern

Quindi immagino che abbia senso avere un tipo di dati Null.

Documentazione indicata anche come typeof null // "object" (non "null" per motivi legacy)

Non sono sicuro di quali siano le ragioni del passato