Dlaczego w JavaScript występuje wartość „null”?

W JavaScript istnieją dwie wartości, które zasadniczo mówią „nie istnieje” - undefinedi null.

Właściwość, do której programista niczego nie przypisał, będzie undefined, ale aby właściwość stała się null, nullmusi być do niej jawnie przypisana.

Kiedyś myślałem, że jest potrzeba, nullponieważ undefinedjest to prymitywna wartość i nullprzedmiot. Tak nie jest, nawet jeśli typeof nullda 'object': W rzeczywistości obie są wartościami pierwotnymi - co oznacza, że undefinedani ani nie nullmogą zostać zwrócone z funkcji konstruktora, ponieważ obie zostaną przekonwertowane na pusty obiekt (trzeba zgłosić błąd, aby ogłosić błąd w konstruktorach).

Oba oceniają również falsew kontekstach logicznych. Jedyną prawdziwą różnicą, o której przychodzi mi do głowy NaN, jest to, że jedna ocenia się , a druga 0w kontekstach numerycznych.

Dlaczego więc jest jedno undefinedi drugie i nulljeśli to tylko dezorientuje programistów, którzy nieprawidłowo sprawdzają null, czy właściwość została ustawiona, czy nie?

Chciałbym wiedzieć, czy ktoś ma rozsądny przykład, w którym konieczne jest użycie, nullktórego nie można wyrazić za pomocą undefinedzamiast tego.

Tak więc ogólny konsensus wydaje się być taki, że undefinedoznacza to „nie ma takiej własności”, podczas gdy nulloznacza „właściwość istnieje, ale nie ma wartości”.

Mógłbym z tym żyć, gdyby implementacje JavaScript faktycznie wymuszały takie zachowanie - ale undefinedjest to całkowicie poprawna wartość pierwotna, więc można ją łatwo przypisać do istniejących właściwości, aby złamać ten kontrakt. Dlatego jeśli chcesz się upewnić, czy właściwość istnieje, musisz użyć inoperatora lub hasOwnProperty()mimo wszystko. A więc jeszcze raz: jakie jest praktyczne zastosowanie oddzielnych wartości dla undefinedi null?

Właściwie używam, undefinedgdy chcę anulować wartości właściwości, które nie są już używane, ale których nie chcę delete. Powinienem użyć nullzamiast tego?

Pytanie tak naprawdę nie brzmi „dlaczego w JS istnieje wartość zerowa” - w większości języków istnieje jakaś wartość zerowa i jest ona ogólnie uważana za bardzo użyteczną.

Pytanie brzmi: „dlaczego JS ma niezdefiniowaną wartość”. Główne miejsca, w których jest używany:

1. kiedy deklarujesz, var x;ale nie przypisujesz do niego, xhold undefined;
2. kiedy twoja funkcja otrzymuje mniej argumentów niż deklaruje;
3. kiedy uzyskujesz dostęp do nieistniejącej właściwości obiektu.

nullz pewnością działałby równie dobrze dla (1) i (2) *. (3) powinien naprawdę od razu zgłosić wyjątek, a fakt, że tak się nie dzieje, zamiast undefinedzwrócić ten dziwny błąd , który później się nie powiedzie, jest dużym źródłem problemów z debugowaniem.

*: możesz również argumentować, że (2) powinno zgłosić wyjątek, ale wtedy musiałbyś zapewnić lepszy, bardziej wyraźny mechanizm dla argumentów domyślnych / zmiennych.

Jednak JavaScript początkowo nie miał wyjątków ani żadnego sposobu, aby zapytać obiekt, czy ma członka o określonej nazwie - jedynym sposobem było (i czasami nadal jest) uzyskanie dostępu do członka i zobaczenie, co otrzymujesz. Biorąc pod uwagę, że nullmiał już cel i możesz chcieć ustawić go jako członka, wymagana była inna wartość poza pasmem. Mamy więc undefinedproblem, jak zauważyłeś, i jest to kolejna świetna „funkcja” JavaScript, której nigdy nie będziemy w stanie się pozbyć.

W rzeczywistości używam undefined, gdy chcę usunąć wartości właściwości, które nie są już używane, ale których nie chcę usuwać. Czy powinienem zamiast tego użyć wartości null?

Tak. Zachowaj undefinedjako specjalną wartość do sygnalizowania, kiedy inne języki mogą zamiast tego zgłosić wyjątek.

nulljest ogólnie lepsze, z wyjątkiem niektórych interfejsów IE DOM, w których ustawienie czegoś nullmoże spowodować błąd. Często w tym przypadku ustawienie na pusty łańcuch zwykle działa.

Najlepiej opisane tutaj , ale podsumowując:

undefined to brak typu i wartości, a null to brak wartości.

Co więcej, jeśli robisz proste porównania „==”, masz rację, wychodzą one tak samo. Ale spróbuj ===, która porównuje zarówno typ, jak i wartość, a zauważysz różnicę.

Myślę, że nie ma powodu, aby mieć jedno nulli drugie, a undefinedponieważ jedyny powód, dla którego wiele osób sugeruje („ undefinedoznacza, że ​​nie ma takiej zmiennej / właściwości”), jest nieprawidłowy, przynajmniej w JavaScript. undefinednie mogę powiedzieć, czy zmienna / właściwość istnieje, czy nie.

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

Jak widać, sprawdzenie foo === undefinednie mówi, czy fooistnieje, a ustawienie w obj.bar = undefinedrzeczywistości nie usuwa bar.

Być może pierwotna intencja autora JavaScript undefinedpowinna przedstawiać „nieistnienie”. Jednak wdrożenie nie potoczyło się w ten sposób.

Jest całkowicie możliwe, że potrzebujesz obu. Na przykład, jeśli odpytujesz WMI, jest całkowicie możliwe, aby klasa zwracała właściwości, które mają wartość null. Są zdefiniowane, po prostu akurat w tym czasie trzymają wartość zerową.

Myślę, że twój wniosek, że JavaScript definiuje undefinedjako „nie ma takiej właściwości” i nulljako „właściwość nie ma wartości”, jest całkowicie poprawny. W języku tak dynamicznym jak JavaScript jest to bardzo ważne rozróżnienie. Stosowanie kaczych znaków oznacza, że ​​musimy być w stanie odróżnić nieruchomość nieistniejącą od niemającej wartości. Jest to nasz podstawowy sposób uzyskiwania informacji o typie. w języku z typami statycznymi istnieje wyraźne rozróżnienie między polem, które jest puste, a polem nieistniejącym. W JavaScript nie jest inaczej. Jednak jest on sprawdzany w czasie wykonywania i może być modyfikowany do tego czasu.

Muszę się zgodzić, że implementacja jest dziwna, ponieważ bardzo często rozróżnienie jest rozmyte. Myślę jednak, że w JavaScript to rozróżnienie jest ważne. A umiejętność przypisywania undefinedjest niezbędna.

Pamiętam, jak jakiś czas temu przeczytałem wpis na blogu o grze RPG online napisanej w JavaScript. Wykorzystał przykłady, w których obiekty były tworzone jako kopie istniejących instancji, a nie jako prototypy (klasy, funkcje, cokolwiek), a następnie były modyfikowane. To naprawdę sprawiło, że zrozumiałem, jak potężne undefinedmoże to być podczas modyfikowania istniejących obiektów, ale nie pamiętam, kto to napisał.

Semantycznie oznaczają różne rzeczy. Typ null ma dokładnie jedną wartość w swojej domenie, null, a właściwość może mieć przypisaną tę konkretną wartość. Niezdefiniowany oznacza wyraźny brak przypisania jakiejkolwiek wartości.

Jako programista Java widzę ogromną różnicę między undefined a null. Kodowanie JavaScript, nie tak bardzo, ponieważ JavaScript nie jest silnie typowany, a różnice między undefined i null są zatarte przez automatyczne konwersje, które są często wykonywane przez środowisko wykonawcze. Przy okazji, często korzystam z tych konwersji; sprawiają, że mój kod JS jest bardziej zwarty i czytelny.

Odpowiadając na twoje pytanie, wartość undefined oznacza, że ​​wartość nigdy nie została ustawiona. Praktycznie rzecz biorąc, zazwyczaj wskazuje to na błąd. Jeśli obiekt yourObject.property jest niezdefiniowany, oznacza to, że z jakiegoś powodu nie ustawiłeś właściwości lub szukam czegoś, co w ogóle nie istnieje. Jest to prawdziwy problem podczas pracy nad projektem z więcej niż jednym koderem.

null oznacza, że ​​jawnie nie ustawiono żadnej wartości. Mówiąc praktycznie, mówisz mi coś o nieruchomości, być może, że nie jest ona używana w tym kontekście lub że wartość nie została jeszcze określona.

W Javie próby uzyskania dostępu do niezdefiniowanego pola zawsze kończą się wyjątkiem. W rzeczywistości kompilator może ostrzegać o tym w kodzie.

Wypróbuj ten przykład:

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

Myślę, że istnieje tutaj bardzo realne zastosowanie dla 2 różnych typów.

Sprowadza się to do dynamicznej natury skryptów JavaScript.

Rzeczy mogą być niezdefiniowane, aby można je było dodać później. Prawdopodobnie dlatego javascript jest tak potężny i rozszerzalny.

jest to ważna funkcja języka, jeśli opuścisz swój program wokół zdarzeniowego paradygmatu 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)

jest to bardzo przydatne, jeśli masz do czynienia z zestawem danych, które wymagają wartości reprezentującej „nic”, aby wskazać jakąś akcję inną niż użycie „nic” do wskazania akcji domyślnej.

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]
 * }
 */

w powyższym kodzie słowo kluczowe null i niezdefiniowany serwer są bardzo jasne i mają różne cele. wyszukiwanie, które nie zostało znalezione w obiekcie filter_func_pt, które zwraca nieokreśloną wartość, oznacza dodanie właściwości do zwracanego obiektu w takiej postaci, w jakiej jest, podczas gdy wartość null wskazuje, że wartość powinna zostać wstrzymana, a nie dodana, oraz obecność jakiejkolwiek prawdziwej wartości w tym case reprezentuje funkcję używaną do przekształcenia wartości przed dodaniem jej do obiektu ret .

null jest piękne

podobnie jak wszystkie inne typy skryptów na żywo.

cite: W JavaScript istnieją dwie wartości, które zasadniczo mówią „nie istnieje” - undefined i null.

Dlaczego chcesz mówić niepoprawne rzeczy ?!

„null” to „pusty obiekt”, tak jak „0” jest „pustą liczbą ” . 0, nie jest niczym - jednak istnieje jako rzecz Type of a Number. null jest oczywiście również puste, ale „jest” i jest to dobrze zdefiniowana rzecz typu obiektu .

Często mówi się o tych rzeczach jako o „typach”, gdy tak nie jest. W rzeczywistości są to „kategorie”. Ale to już koniec.

Więc trzymam się tego, aby powiedzieć, że „null” jest Typem Obiektu bez Rodzaju. A „null” mówi: „Bardzo istnieję [!], Ale nie mam treści tego rodzaju”.

Podczas gdy undefined nie ma zarówno typu, jak i rodzaju, podczas gdy undefined jest również jego definicją typu. Nieokreślony typ typu staje się jego charakterystyczną typologią. Coś w rodzaju pytania [czy „nic” nie istnieje i jak definiujesz „nic”?].

cite: undefined ani null mogą zostać zwrócone z funkcji konstruktora, ponieważ obie będą konwertowane na pusty obiekt

Po raz kolejny udało ci się powiedzieć niewłaściwą rzecz. Oczywiście, że nie, „nieokreślony” nie jest przedmiotem, to zwykły Token, który my, ludzie, rozumiemy; ale w przeciwieństwie do tego null jest - i to ci mówi: jego typ jest poprawny, ale rodzaj, którego szukasz, nie jest w nim zawarty, a przynajmniej nie jest w tej chwili. Odwiedź nas później, gdy umieścimy w nim \ przypisany obiekt \.

cite: Jedyną prawdziwą różnicą, o której przychodzi mi do głowy, jest to, że jedna zwraca się na NaN, a druga na 0 w kontekstach numerycznych.

To właśnie stanowi sedno ich podstawowego rozróżnienia, jak wspomniano: undefined to zwykły symbol, a ponieważ składa się z tego samego „materiału genetycznego”, co jego odlegli krewniacy: łańcuchy, operacja [+ undefined] spowoduje jego zamianę na NaN, podobnie null oczywiście przekształci się w prawidłowy rodzaj 0 \ Number, aw przeciwieństwie do undefined , który przekształci się w łańcuch (! Który nie jest pusty!) I właśnie dlatego zwraca zamiast tego NaN . Gdzie: + undefined >> + "undefined" >> NaN. Ponieważ kontekst numeryczny oczekuje jawnej wartości.

Podczas gdy kontekst boolowski oczekuje odniesienia - nie znajduje niczego do konwersji i zwraca „fałsz”.

Przejdźmy teraz ...

cite: Więc jeszcze raz: jakie jest praktyczne zastosowanie oddzielnych wartości dla undefined i null?

Spróbuję podać tylko dwa przykłady empiryczne i mam nadzieję, że wystarczą

oElement.onclick >> null

// oznacza - własność istnieje; jego oczekiwana wartość to Type: Object , a ten oElement obsługuje zdarzenie „onclick”!

oElement.innerText >> ""

// oznacza - własność istnieje; jego oczekiwana wartość to Type: String , co oznacza, że ​​oElement obsługuje właściwość „innerText”.

w obu przypadkach - jeśli otrzymasz „undefined”, oznacza to, że właściwość nie istnieje; nie jest obsługiwany lub ma nieprawidłową implementację (dostawca UA).

Trzymaj się mrozu i baw się dobrze.

po przeczytaniu niesamowitej dyskusji dotyczącej undefined vs null, małe wyszukiwanie w Google zaprowadziło mnie do Dokumentacji Mozilli https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/null, o czym wspomina się - null jest często pobierane w miejscu, w którym można się spodziewać obiektu, ale żaden obiekt nie jest istotny.

Nie jest podobny do wzorca obiektu o wartości Null https://en.wikipedia.org/wiki/Null_object_pattern

Więc myślę, że ma to sens, aby mieć typ danych Null.

Dokumentacja wymieniona również jako typeof null // "object" (nie "null" z powodów starszych)

Nie wiem, jakie są starsze powody