@winerfresh:
Wystarczy porządnie wgłębić się w język. Czemu ludzie mogą czytać praktycznie specyfikacje Javy czy C++, a co najmniej suche książki o tych językach, a ni cholery nie mogą poczytać DOGŁĘBNIE o JavaScripcie? Poziom wśród programistów JavaScript jest po prostu żałosny. Pełno script kiddies. Powszechne jest głupie przeświadczenie, że w języku dzieją się jakieś czary i że normalny człowiek nie może tego zrozumieć. Co gorsza, mówią tak też Javowcy czy C++, którzy także w dupie mają czytanie specyfikacji JS i myślą, że wszystko w JS-ie miało pewnie być takie samo, jak w "ich" języku, ale twórcy nie wyszło. Tymczasem w Javie czy C++ dziedziczenia prototypowego nie ma, a funkcyjność raczkuje w porównaniu z JS-em (którego funkcyjność jest z kolei prymitywna w stosunku do OCamla i innych języków, ale mniejsza z tym).
Tabelka prawdy... phi!
Masz dwie opcje.
Pierwsza to olanie == i korzystnaie z ===. Możesz wprowadzić to nawet do standardu kodowania. Zresztą, jest to domyślnie obecne w JSLincie i wiele osób == po prostu nie używa. Ja sam praktycznie tego nie używam, z drobnymi wyjątkami.
Druga opcja to zajrzenie do specyfikacji. Tam to jest opisane.
Pierwsze kroki algorytmy rozprawiają się z przypadkiem, gdzie oba argumenty są tych samych typów. U Ciebie tak jest w pierwszej linijce. Pusty string i string z jednym znakiem ('0') nie są równe -- logiczne.
Dalsze kroki mówią konkretnie o null / undefined -- że są równe (masz i takie porównanie). Dalej, jeśli jednym argumentem jest String, a drugim Number, to String zamieniany jest na Number. Dlatego '0' (po zamianie) jest równe 0. Pusty string zamieniany na liczbę daje 0, więc znowu porównanie '' == 0 zwraca true.
Może najbardziej zastanawia Cię ostatnia linijka? Cóż... napisałem już, że przy porównaniu Stringa i Numbera, zamieniamy na Number. Dowolny ciąg białych znaków zamieniany jest na liczbę 0. Mamy więc 0 == 0, czyli true.
I tak dalej, i tak dalej. Da się to ogarnąć, wbrew pozorom, jeśli się nad tym posiedzi.
Tym bardziej, że to akurat bodaj najbardziej chamski fragment specyfikacji. Najtrudniejszy do zapamiętania. Nie sądzę, by był trudniejszy niż automatyczne reguły konwersji/promocji typów w C++!
Tak samo ludzie się łapią za głowę, czemu [] == {} zwraca false, a {} == [] daje już błąd składni. Albo czemu [] + {} daje '[Object object]', a {} + [] daje 0. A wystarczy zerknąć do gramatyki by wiedzieć, że {} nie zawsze będzie parsowane jako literał obiektowy...
Bardzo niewielki odsetek tzw. "programistów JavaScript" rozkminia taką wiedzę. Nie chce im się. Jakoś mam wrażenie, że już więcej Javowców czy C-sharpowców uczy się swojego języka na poważnie. A JS jest sporo mniejszy, prostszy!
@pseudoprogramista:
Spróbuj może "JavaScript -- Mocne strony" Douglasa Crockforda? Tylko czytaj super, super uważnie. On pisze bardzo zwięźle, rzadko powtarza się 2x. Np. zdanie "Prototypy nie są brane pod uwagę przy zapisie wartości" jest szalenie ważne, a występuje gdzieś w środku paragrafu.
Na to, że prototypy to nie "wadliwa wersja" programowania obiektowego, fajnym argumentem jest prostota. W C++ czy Javie, językach klasycznych, masz klasy i obiekty. Klasy dziedziczą niby coś po innych klasach, ale tak naprawdę nic nie jest dziedziczone ani inicjalizowane (oprócz takich rzeczy jak składowe statyczne) zanim pojawi się pierwszy obiekt danej klasy.
To tak naprawdę zagmatwane, choć dla nas zrozumiałe, bo uczymy się tego od niemal pierwszych kroków z programowaniem.
Tymczasem, w dziedziczeniu prorotypowym jest prościej. Obiekty dziedziczą po obiektach. I tyle. Prototypy to zwykłe obiekty. Prototypem jest każdy, najzwyklejszy obiekt, po którym akurat ktoś odziedziczył.