Pożal się Google

To co zrobiło Google, to żart. Cała historia z wewnętrznymi, nie do końca miłymi mailami z Google’a, które wyszły na światło dzienne, sam Dart i otoczka PR-owa jaką ma, to jedno wielkie nieporozumienie. Google się nie popisało i, moim skronym zdaniem, wyjdzie to tylko na dobre open webowi.

Wyobraźmy sobie, co by się stało gdyby Dart rzeczywiście powalał na kolana i miałby świetnie zaimplementowaną, super wydajną i dostępną out of the box w Chrome maszynę. Szybko znalazłoby się grono fan boy’ów, którzy bez zastanowienia zaczęliby pisać aplikacje „only for Chrome”, bądź „works best with Chrome”, z ewentualną, wątpliwej jakości, kompilacją do powolnego i starego JavaScriptu dla „gorszych przeglądarek”. (BTW. hello world w Dartcie skompilowany do JS to 17000 linii kodu :D).

Po chwili okazałoby się, że Google, wykorzystując swoją pozycję lidera na wielu rynkach, zaczyna (pośrednio – przez zadowolonych użytkowników) wymuszać na innych producentach implementację Darta. No dobra – wygrał, ale w czym problem, pytacie? W tym, że Google nie raczy podzielić się odpowiedniej jakości specyfikacją języka i Mozilla, MS, czy Opera zostają zmuszone do reverse engineeringu z Chrome’a. Brzmi jak głupia apokaliptyczna wizja? Problem w tym, że ten przypadek już mieliśmy z protokołem SPDY, ponieważ Mozilla została zmuszona przez Google do zgadywania jak on w szczegółach działa. Koniec końców, po wykonaniu nieprzyjemnej pracy, pozostali producenci i tak kończą z „gorszą” implementacją. Innymi słowy – wracamy do czasów wojny przeglądarek i nieczystych zagrań. W dodatku pieczę nad specyfikacją języka sprawuje Google i wcale nie mamy pewności, czy się nią podzieli.

Dalej brzmi to jak bajka? Ciekawostka – opublikowana „specyfikacja” (wczesny draft oczywiście) Darta ma 70 stron, a specyfikacja wiele razy mniej złożonego ES5 250 stron. I nie, nie z powodu wielkości fonta. Mówicie – są języki, które radzą sobie bez specyfikacji – Python, Ruby – i są świetne (ktoś wymienił PHP – strzał w stopę w tej dyskusji :D). Tak, ale implementuje je jeden producent. W webie to nie działa i nigdy nie działało. Chcecie żeby przeglądarki miały spójne implementacje, to nie cofajcie się teraz o krok wstecz (prawie jak cofać się do tyłu :P). Nie po to wielokrotnie straciliśmy włosy na głowie (a i twarz też, bo czasami głupio się przyznać – „jestem programistą JavaScript”), by zapominać czego nauczyła nas historia. Nie po to został włożony i nadal jest wkładany ogromny trud w to, by ujednolicić i dogłębnie dospecyfikować wykorzystywane przez nas technologie, byśmy teraz tę pracę skreślili i zaczęli od początku. W szczególności, że…

Na poważnie, czyli z forkowaniem za pan brat

… nie ma takiej potrzeby. Wiele osób, w tym i ja, narzeka na JavaScript. Niektórzy wciąż nie wiedzą ile naprawił ES5 ze strict modem, niektórzy też nie zdają sobie sprawy ile jeszcze problemów jest do rozwiązania. Większość jednak narzeka i moim zdaniem słusznie. Na szczęście trwają prace nad ES6 aka Harmony aka ES.next (w których oczywiście Google uczestniczy). O ile, co smutne, ale racjonalne, ES5 nie wprowadził żadnych (może poza strict modem) przełomowych zmian w JavaScriptcie, o tyle ES6 takie zmiany ma wprowadzić, włącznie z dużymi w składni (choć Marcoos mi ostatnio powiedział, że myślą o wydaniu pośrednim, bez zmian składniowych, stąd pośrednie nazwy – oby pomysł upadł – miejcie jaja, Panowie!).

Na pewno jednak ten właściwy ES6 zrywa ze wsteczną zgodnością. Jest więc pole do popisu i czas, by, jeśli ktoś się postara, niemal od nowa projektować pewne aspekty języka. Można mieć tylko jeden zarzut do Harmony – nic nie wiemy o planowanym terminie zakończenia prac. Jednym z argumentów zwolenników strategii Google jest to, że „nie chcieli czekać, aż się powolny komitet naprodukuje i jako największy gracz wzięli sprawy w swoje ręce”. Brzmi niemal przekonująco. Poza tym, że Darta też szybko w wersji stabilnej i szeroko dostępnej nie zobaczymy (jeśli w ogóle). W dodatku praktyka odległej wersji finalnych HTML5 i CSS3 pokazuje, że dzięki wczesnym prototypom częściowym możemy raz, że wiele poprawić jeszcze podczas prac nad specyfikacją, dwa że płynnie przejść pomiędzy wersjami i szybko z nowych ficzerów korzystać. Co prawda JavaScript, to nie CSS, gdzie możemy sobie pozwolić na graceful degradation, jednak gracze typu Google bez problemu mogą serwować inne źródła w zależności od zdolności przeglądarki (a i tak mówimy o kompilacji ES6 do ES3, bo polyfilli to nie będzie). W dodatku wiele osób pisze aplikacje w JavaScript na w miarę przewidywalne środowiska (intranet, komórki, serwer), gdzie problemu nie ma w ogóle.

Stąd przechodzę do pytania – dlaczego Google zamiast forkować istniejące rozwiązania, nie zdecydowało się na wczesną, testową implementację ES6 w V8 (choć zdaje się chodziły takie słuchy)? Dzięki temu mogłoby wpływać na prace komitetu (wprowadzać ficzery w V8 i pokazywać, że świetnie się przyjmują wśród developerów, bądź po prostu dobrze działają), przyspieszyć je i poprawić zawczasu wiele wątpliwych kwestii. Spotkałem się też z argumentem, że konkurencja jest przecież dobra. Owszem, mamy na szczęście kilku producentów i stosunkowo równomierny ich udział w rynku. Moim zdaniem to wystarcza, co widać choćby na przykładzie wcześniej przeze mnie wspomnianych HTML5 i CSS3 (kontrargument swoją drogą, to to, że wyścig rodzi kiepskie implementacje – vide koszmarne formsy).

Bawi mnie niezmiernie jeszcze jedna kwestia. Dart wcale nie jest fajny. Wygląda jak Java, jest toporny, nie ściągnie gawiedzi jak laska z cycem na wierzchu zwana CoffeeSkryptą (BTW. uroda z inteligencją w parze nie idzie – to może ten Dart taki zły nie jest? Małżeństwo z rozsądku? ;). Nie jest też wybitnie rewolucyjny, ani… odległy od ES6. Koncepcje, które znalazłem w Dartcie widywałem też w materiałach o ES6. Jego implementacja też póki co nie powala na ziemię pod względem wydajności, a był to przecież podobno jeden z powodów porzucenia JS. W dodatku pokazuje to jak wiele pracy jest do wykonania, by dogonić już wiele lat rozwijany engine V8. To jest kolejny powód dla którego nie rozumiem decyzji Google’a.

Jest też plus

Jest jednak jedna rzecz, która mi się podoba w Dartcie – szersza biblioteka standardowa (włączając w to sensowną implementację DOM-a). Uważam, że w tej chwili jednym z największych problemów JavaScriptu, jest brak ustandaryzowanych (mniej, lub bardziej formalnie) podstawowych narzędzi. Ja np. w najświeższym projekcie postanowiłem wykorzystać deferred i es5-ext skompilowane do niecommonjsowej postaci. Zastanawiałem się jednak, czy nie wolę underscore’a. Ale zaraz – deferred i tak korzysta z es5-ext, więc ten kod i tak załaduję (tutaj ukłon w kierunku Medikoo – na szczęscie es5-ext jest 100% zmodularyzowane, więc konfigurowalne). Potrzebowałem jeszcze czegoś do DOM-a. Z jQuery nie skorzystam, bo nie potrzebuję 90% (dosłownie!) tej biblioteki, w dodatku pokrywa mi się z deferred i trochę es5-ext, no i szukałem czegoś lekkiego. Trafiłem na xui.js, które okazało się niedopieszczone. Szukałem czegoś do single page apps – Backbone? Nieee… ktoś wymyślił, że dla XHR-a, delegate’a i deferred (i czegoś jeszcze?) skorzysta z jQuery. Jeszcze gorzej chyba ze Spine.js, gdzie znalazłem jakoś z 5 odniesień do jQuery, ale zaszytych głęboko w kodzie, bez możliwości łatwej podmiany. Przy całym tym śmietniku idiotycznych decyzji twórców tych (i wielu innych) narzędzi, są myślące osobniki, które wyprodukowały takie mini biblioteki jak Crossroads, czy js-signals. Robiące dokładnie jedną rzecz i nie zawierające zbędnych zależności.

Żalę się generalnie, ale nie bez powodu. Dart rozwiązałby połowę moich problemów. Mamy i promise’y, i wygodniejszego DOM-a. Dużo więcej ciekawych rzeczy niestety nie znalazłem, ale początek jest dobry. Uważam, że to jest aspekt języka, na który powinny zwrócić uwagę osoby pracujące nad ES6. Wiem na pewno, że jeden problem zostanie rozwiązany – zostaną wprowadzone natywne moduły. Trochę martwi mnie ich rozbieżność w stosunku do CommonJS-owej wersji (i trochę niezrozumiała dla mnie decyzja o wprowadzeniu nowej składni), ale może uda się to zgrabnie rozegrać.

Podsumowując

Nie wierzę, a przynajmniej nie chcę wierzyć, w sukces Darta. Póki co niczym mnie nie zainteresował i nie zamierzam się w niego zagłębiać. Mam nadzieję, że byłaby to strata czasu.

Zauważyliście pewnie, że brakuje w treści linków do źródeł. Tak – nie chce mi się. Google w tym wypadku pomoże :). Poza tym, nie chcę być wyrocznią, nie chcę napisać pracy doktorskiej, nie chcę nikogo zniszczyć, wypunktowując go bezlitośnie. Co więcej, możliwe, że sam niedługo zmienię na co poniektóre tematy zdanie, bo i nie mam pełnej wiedzy o tym co się dzieje i co się stanie. Powyższa opinia rodziła się we mnie jednak już kilka tygodni, więc nie jest też pisana pod wpływem wielkich emocji. Może więc jest racjonalna :).

Podobne wpisy:

1. Wrocław wita JavaScript – Meet.JS i Wrocław GTUG
2. Zarezerwowane słowa kluczowe w JavaScript – gramatyka języka
3. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings

Spośród listy tematów do opracowania wybrałem pierwsze 3, które moim zdaniem zgrabnie się łączą. Są to zasięg (scope), hoisting (widziałem tłumaczenie do wyniesienie, ale brzmi strasznie) oraz deklaracje funkcji (function declaration – dalej: FD) i wyrażenia funkcyjne (function expression – dalej: FE). Mam nadzieję, że rozjaśnienie tych tematów pozwoli zaoszczędzić komuś trochę czasu :).

Artykuł będzie składał się z dwóch części. Tę część poświęciłem typom zasięgu oraz domknięciom. Następna będzie dotyczyła (edit: już jest dostępna) hoistingu i funkcji.

Sprawdź się!

Na początek niekrótki zestaw krótkich testów. Spróbuj rozpoznać co wydrukuje każdy console.log. Skrypt z wszystkimi pytaniami, wraz z odpowiedziami wrzuciłem na Gista.

Cz.1.

var a = 1;
for (var a = 0; a < 10; ++a) {}
console.log('1.1:', a);
 
 
{
    var b = 1;
}
console.log('1.2:', b);
 
 
var c_fn = function () {
    var c = 1;
};
c_fn();
console.log('1.3:', c);

Cz.2.

var a = 1;
var a_fn = function () {
    return a;
};
 
console.log('2.1:', a_fn());
 
(function (fn) {
    var a = 2;
    console.log('2.2:', fn());
})(a_fn);
 
(function (fn) {
    a = 3;
    console.log('2.3:', fn());
})(a_fn);
 
console.log('2.4:', a_fn());
 
 
var b = [1, 2, 3, 4],
    b_i = 0;
 
for(; b_i < b.length; ++b_i) {
    b[b_i] = function () { return b_i; };
}
console.log('2.5:', b[0]());

Zasięg funkcyjny i blokowy

Jeśli wychowałeś się na JavaScriptcie, pierwszy test nie powinien sprawić Ci żadnego problemu. Jeśli jednak jesteś programistą Javy, bądź języka C(|++|#), to mogłeś odpowiedzieć źle. Jaka jest różnica? JavaScript jest językiem o zasięgu funkcyjnym, zaś pozostałe o zasięgu blokowym.

Analogiczny kod napisany w C++ (dla przykładów 1.1 i 1.2, ponieważ 1.3 jest niewykonalny) zwróciłby odpowiednio 1.1: 1, 1.2: error: ‘b’ was not declared in this scope.

int main() {
    int a = 1;
    for (int a = 0; a < 10; ++a) {}
    cout << a; // -> 1
 
    {
        int b = 1;
    }
    cout << b; // -> błąd kompilacji
 
    return 0;
}

Jak widać, blok, bądź konstrukcja for powodują pojawienie się nowego zasięgu. Po wykonaniu się pętli a wciąż jest równe 1 (więcej przykładów dla C++). Java zachowałaby się nieco inaczej, uniemożliwiając redefiniowanie zmiennej o tej samej nazwie, jednak ogólna zasada byłaby identyczna.

JavaScript za to, określając sobie zasięg zmiennej, nie zwraca uwagi na żadne bloki. Jedynym ograniczeniem dla niego jest funkcja. Każda zmienna zdefiniowana w funkcji jest widoczna w tej funkcji i w funkcjach zdefiniowanych w tej funkcji, ale nigdzie poza nią. Dzięki temu otrzymamy: 1.1: 10, 1.2: b, lecz: 1.3: ReferenceError.

Zostałem kiedyś zapytany, czy istnieje możliwość podejrzenia wewnętrznego scope’a funkcji. Odpowiedź jest na szczęście przecząca (przynajmniej wedle mojego stanu wiedzy). Tak ścisłe ograniczenie zasięgu pozwala nam bezwarunkowo zabezpieczyć kod przed ingerencją z zewnątrz. Stąd na pewno gdzieś już widziałeś konstrukcję:

(function () {
...
}());

Jest to samowykonująca się funkcja. Wszystko co zostanie zdefiniowane wewnątrz niej jest niedostępne z zewnątrz (o ile nie zostało zwrócone).

Zasięg statyczny

Napisałem, że zmienna zdefiniowana w funkcji jest widoczna w tej funkcji i w funkcjach zdefiniowanych w tej funkcji. Takie podejście nazywa się statycznym zasięgiem (druga nazwa to zasięg leksykalny – lexical scoping), z tego względu, że określenie zasięgu polega jedynie na analizie statycznego kodu programu. Przeciwstawnym podejściem jest dynamiczny zasięg, a więc scope funkcji określany jest w momencie jej wywołania, a nie definicji.

Przyjrzyjmy się drugiemu przykładowi do tej części:

var a = 1;
var a_fn = function () {
    return a;
};
 
(function (fn) {
    var a = 2;
    console.log('2.2:', fn()); // -> 1
})(a_fn);

Jak widać, mimo zadeklarowania var a = 2 w miejscu wywołania funkcji a_fn() zostanie zwrócone 1. Tak więc możemy powiedzieć, że funkcja zapamiętała otoczenie swojej definicji. Zachowanie takie nazywa się domknięciem, czyli jest to sławetny postrach początkujących – closure. O domknięciach chciałbym napisać kiedyś osobny artykuł, ale dla utrwalenia jeszcze jeden przykład:

var a = 1;
var outer = function () {
    var a = 2;
    return function () {
        console.log(a);
    };
};
 
var inner = outer();
inner(); // -> 2

Przez referencję, głupcze!

var b = [1, 2, 3, 4],
    b_i = 0;
 
for(; b_i < b.length; ++b_i) {
    b[b_i] = function () { return b_i; };
}
console.log('2.5:', b[0]()); // -> 4

To jest chyba najbardziej znany przykład na to, że zmienne zamykane są przez referencję, a nie przez wartość. Wszystkie cztery funkcje wskazują na tę samą zmienną b_i i są od niej zależne aż po swój kres. Dobrze o tym pamiętać, bo jest to źródłem wielu błędów.

Jeśli jednak chcemy aby funkcje zwracały odpowiednio: 0, 1, 2, 3, to co zrobić aby naprawić powyższy przykład? Zastosować kolejne domknięcie, tym razem jednak przekazując naszą zmienną jako argument, ponieważ te przekazywane są przez wartość (tylko typy proste).

var b = [1, 2, 3, 4],
    b_i = 0;
 
for(; b_i < b.length; ++b_i) {
    b[b_i] = (function (i) {
        return function () { return i; };
    }(b_i));
}
console.log(b[2]()); // -> 2

Zasięg blokowy w JavaScriptcie

Życie z niedoskonałym zasięgiem funkcyjnym (czasem połączonym z domknięciami) bywa nieprzyjemne. W poprzednim przykładzie musieliśmy dodać nadmiarową funkcję, co oznacza zaciemnienie kodu oraz spadek wydajności. Tak samo musielibyśmy się zachować gdybyśmy chcieli aby pętla for mogła iterować po wartości, która nie przesłoniłaby nam innej, zdefiniowanej wcześniej.

var i = 10;
...
for (var i = 0; i < 5; ++i) {}
...
console.log(i); // -> 5! 10 zostało przesłonięte

Twórcy EcmaScriptu szukali więc wyjścia i już w wersji EcmaScript 4 (trochę historii porzuconego standardu) zamierzali wprowadzić słowo kluczowe let mające służyć deklarowaniu zmiennej o zasięgu lokalnym – blokowym. Standard (a w zasadzie jego zalążek) został niestety porzucony na kilka lat i w okrojonym stanie wróci pod nazwą EcmaScript 6 aka Harmony (mój kolejny pomysł na wpis :).

Okazuje się jednak, że część porzuconego EcmaScriptu 4 została zaimplementowana w silniku Firefoksa. Są to JavaScript 1.7 i JavaScript 1.8. Zmienne lokalne są częścią wersji 1.7 i po przestawieniu silnika w odpowiedni tryb można z nich do woli korzystać. Co ciekawe silnik RingoJS domyślnie działa w wersji 1.8, co dawałoby mu ogromną przewagę nad silnikiem Node’a, gdyby nie jego słaba wydajność :).

Przykład wykorzystania let:

<script type="text/javascript;version=1.8">
    var b = [1, 2, 3, 4],
        b_i = 0;
 
    for(; b_i < b.length; ++b_i) {
        let i = b_i;
        b[b_i] = function () { return i; };
    }
    console.log(b[2]()); // -> 2
    console.log(i); // -> ReferenceError
</script>

Ciekawym pytaniem na koniec jest, czy zasięg funkcyjny ma jakiś sens? Czy wraz z wejściem zmiennych lokalnych nie powinniśmy porzucić var?

Ciąg dalszy nastąpi…

Podobne wpisy:

1. Co lepiej wiedzieć o JavaScriptcie cz.2.: hoisting, deklaracje funkcji i wyrażenia funkcyjne
2. Konsola Firebuga – „echowanie” Javascriptu
3. Obiektowy Javascript cz.1. – obiekt Twoim przyjacielem

Kto nie był w zeszłym roku na konferencji Front Trends ten, czytając świetne recenzje jakie dostała, na pewno tego żałował. Sam byłem w Warszawie i wiem, że dobrze zainwestowałem swój czas i pieniądze, bo to jedyne tego typu wydarzenie w Polsce, jakie pamiętam. Wystarczy spojrzeć na listę prelegentów, którzy wzięli udział w konferencji. Douglas Crockford, Tantek Çelik, Peter-Paul Koch to bez wątpienia gwiazdy, których przedstawiać nie trzeba. Jednak bardzo dobre wrażenie zrobili na mnie również mniej znani prelegenci, jak Christian Johansen, Zbigniew Braniecki (jako moderator panelu dyskusyjnego), czy Andrea Giammarchi.

Jedyny zarzut (poza drobnymi problemami organizacyjnymi i kilkoma odstającymi poziomem prelegentami), jaki słyszałem w stosunku do zeszłorocznej konferencji to zbyt małe nastawienie na JavaScript. W tym roku Damian Wielgosik i Paweł Czerski, twórcy Front Trends, postanowili wyjść na przeciw krytykom i już za 2 tygodnie, w dniach 18-20 maja w Warszawie odbędzie się konferencja i 2 dni warsztatów pod nazwą Falsy Values. Tym razem, z pewnością, będzie to „True JavaScript Event”. W dodatku obsada zapowiada się jeszcze ciekawiej i równiej. Nie dość, że gościć będą wszyscy wielcy z Front Trends (poza PPK-em), to spotkać będzie można również kilku nowych, dobrze znanych, developerów, m.in. Dmitry’a Soshnikova, Juriy’a „kangax” Zaytseva oraz Kornela „porneL” Lesińskiego.

W chwili obecnej zakupić można jeszcze bilety wstępu (upoważniające również do udziału w konferencji) na wszystkie warsztaty poza jednymi prowadzonymi przez Tanteka Çelika. Do wyboru mamy więc node.js, wstęp do JavaScriptu, gry, ECMAScript 5, Test Driven Development i aplikacje desktopowe. Można zakupić też bilet jedynie na piątkową konferencję. Ceny wahają się w zależności od tematu warsztatów i długości (są jedno i dwudniowe) i wydaje mi się, że nie są wygórowane, w szczególności kiedy porównamy je z dotyczącymi podobnych eventów organizowanych za naszą zachodnią granicą.

Jeśli o mnie chodzi, to ze względu na studia pojawię się tylko w piątek na konferencji (dziękuję tutaj Damianowi za zaproszenie). Zapowiada się wspaniały dzień, ponieważ plan prelekcji jest wyśmienity. Wiem, że ani nie będę mógł się spóźnić (Douglas Crockford na początek), ani wcześniej wyjść (Tantek Çelik na koniec), ani nawet przysnąć w środku (Dmitry Soshnikov). W szczególności nie mogę doczekać się występu tego trzeciego, ponieważ będzie mówił o ECMAScript 6, a kto czytał mnie wcześniej, wie, że interesuje mnie rozwój tego standardu.

Tak więc, do zobaczenia w Warszawie!

Podobne wpisy:

1. JavaScript na jesień 2011
2. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings
3. Obiektowy JavaScript i właściwości chronione – w poszukiwaniu Świętego Graala

Zauważyłem dzisiaj, że Opera wyrzuca błąd w kodzie, który pod nią testowałem. Okazało się (po dłuższej chwili szukania, bo wersja 10.63 jaką miałem zainstalowaną kompletnie nie trafia z linią wystąpienia błędu), że problem tkwił w użycia słowa delete w literale obiektu. Przykładowo:

var obj = {
	delete: 'eee?'
};

Słowo to jest słowem kluczowym, jednak nie mogłem znaleźć sensownego powodu (typu problem z jednoznacznością zapisu), który wymuszałby zarezerwowanie go również w takim kontekście. Kod ten działa pod Firefoksem i Google Chrome (również z wywołaniem obj.delete), byłem więc ciekaw kto ma rację. Nie ukrywam przy tym, że nie jestem miłośnikiem silnika JavaScript w Operze. Miewałem z nim problemy (i nie tylko ja) i nie przepadam też za całą przeglądarką. Kilka razy jednak okazało się, że to Opera poprawniej (a dokładnie bardziej bezwzględnie) traktuje błędy w kodzie HTML, więc nie byłem pewien rezultatu.

W celu rozwiązania zagadki sięgnąłem do specyfikacji ECMAScript 5.

Zarezerwowane słowa

Najpierw zbiór zarezerwowanych słów (7.6.1.1):

ReservedWord ::
      Keyword
      FutureReservedWord
      NullLiteral
      BooleanLiteral

Jak widać zbiór ten składa się ze słów kluczowych (głównie takich, które są wykorzystywane w tej chwili), przyszłych (takich które mogą być) oraz null, true, false.

Lista słów kluczowych obecnie używanych:

Keyword :: one of
    instanceof        typeof
    break             do
    new               var
    case              else
    return            void
    catch             finally
    continue          for
    switch            while
    this              with
    debugger          function
    throw             default
    if                try
    delete            in

Jak widać słowo delete występuje w tej liście. Nic dziwnego – w końcu ma specjalne znaczenie. Nic to jednak nie oznacza w kontekście obiektów.

Ciekawostka – na liście tej nie ma słowa undefined. Wydawałoby się, że być powinno, ponieważ podobne słowo null jest zarezerwowane. Okazuje się, że nie. Ma to związek z tym, że wartość undefined nie jest specjalnie chroniona i można zrobić z nią np. tak:

typeof undefined; //-> 'undefined'
undefined = 2;
typeof undefined; //-> 'number' sic!

Nie testuj więc nigdy val === undefined, lepiej typeof val === 'undefined'. Koniec ciekawostki.

Przyjrzyjmy się teraz słowom zarezerwowanym z myślą o przyszłych pokoleniach:

FutureReservedWord :: one of
    class             enum
    extends           super
    import            const
    export

Dodatkowo w strict mode mamy:

implements    let         private      public    yield
static        interface   package      protected

Ciekawostka numer dwa. Jak widać zarezerwowane są słowa private i protected. Może się więc kiedyś doczekam właściwości chronionych :). Choć z drugiej strony zapisałem się ostatnio na listę dyskusyjną poświęconą ECMAScript i panowie w komitecie strasznie tam nudzą, więc data pewnie bliska nie będzie.

Wszystkie wymienione wyżej słowa składają się na grupę słów zarezerwowanych. Teraz musimy się dowiedzieć jaką rolę pełnią przy opisie gramatyki literału obiektu i sposobach dostępu do jego właściwości.

Identyfikatory

Specyfikacja ECMAScript 5 wyszczególnia jeszcze dwie grupy, które będą nas interesować. identyfikatory (ang. Identifier) i nazwy identyfikatorów (ang. IdentifierName). Miałem tu problem z tłumaczeniem, ponieważ nie rozumiem w pełni znaczenia tych grup, tak więc przetłumaczyłem je najbardziej wprost jak się dało. Nazwy identyfikatorów to grupa składająca się z:

IdentifierName ::
        IdentifierStart
        IdentifierName IdentifierPart

Nie będę się rozwodził co wchodzi w skład tego zbioru. W skrócie powiem tylko, że znaki $ _, litery, unikodowe sekwencje (np. \u0061 -> "a"), oraz inne unikodowe znaki specjalne (Mn, Mc, Nd, Pc, Zwnj, Zwn) i cyfry (jednak obydwie grupy nie mogą wystąpić na początku). Tak więc nazwy identyfikatorów to wszelkie ciągi znaków, które spełniają powyższy warunek – w tym także nasze słówko delete.

Za to identyfikatory to:

Identifier ::
        IdentifierName but not ReservedWord

Czyli identyfikatorem zmiennej (12.2 – identyfikator zmiennej to Indentifier) nie może być nasze słowo delete, czy var (to w kontekście JavaScriptowego Quizu, który opublikował dzisiaj Damian Wielgosik). To zrozumiałe, bo inaczej moglibyśmy napisać:

var var = 'a';

I powinno mieć to jakieś znaczenie.

Identyfikatory w literałach obiektów

Wiemy już, że mamy dwie grupy – identyfikatory oraz identyfikatory plus zarezerwowane słowa, czyli nazwy identyfikatorów. Teraz pora na meritum. Z czego składają się literały obiektów (11.1.5)?

ObjectLiteral :
      { }
      { PropertyNameAndValueList }
      { PropertyNameAndValueList , }
PropertyNameAndValueList :
      PropertyAssignment
      PropertyNameAndValueList , PropertyAssignment
PropertyAssignment :
      PropertyName : AssignmentExpression
      get PropertyName ( ) { FunctionBody }
      set PropertyName ( PropertySetParameterList ) { FunctionBody }
PropertyName :
      IdentifierName
      StringLiteral
      NumericLiteral
PropertySetParameterList :
      Identifier

Przeanalizujmy to. Najpierw mamy literał obiektu (ObjectLiteral), który może być pusty, składać się z listy nazw właściwości i wartości, bądź listy nazw właściwości i wartości zakończonej przecinkiem (tutaj błąd IE6/7/8).

Następnie mamy konstrukcję, która jest „joinem” par nazwa właściwości i wartość oddzielonych przecinkami.

Następnie PropertyAssignment składa się z setera i getera oraz PropertyName : AssignmentExpression. Zaś PropertyName to… Tadam – IdentifierName, StringLiteral, NumericLiteral.

Jak już wiemy nazwy identyfikatorów zawierają również słowa kluczowe. Tak więc konstrukcja:

var obj = {
	delete: 'eee?'
};

Powinna działać, a w Operze 10.63 i z tego co się dowiedziałem również najnowszej Operze 11 wyrzuca błąd:

>>> var obj = { delete: 'wtf' };
...
Syntax error at line 1 :
var obj = { delete: 'wtf' };
------------^
expected '}', got keyword 'delete'

Identycznie zachowuje się dla pozostałych słów z grupy słów kluczowych. Tak więc jest to jednak błąd.

Nie będę tego już tutaj dowodził, ale dostęp do właściwości obiektu (11.2.1) również zezwala na użycie słów kluczowych po kropce, tak więc poprawną konstrukcją jest:

obj.delete;

Co Opera również uznaje za błąd.

Co ciekawe błąd (bądź nieścisłość) znalazłem też w Mozilla Developer Center.

Również Safari nie jest wolne od błędu ze słowami kluczowymi. Nie mogę teraz sprawdzić, ale wydaje mi się, że słowo class narobiło mi ostatnio problemów. Kontekst był identyczny jak w przypadku Opery.

Wnioski

Mam nadzieję, że się nie pomyliłem nigdzie :) Czytanie specyfikacji proste nie jest i jeśli tak się zdarzyło, że coś namotałem proszę o komentarze.

Tak więc jeśli jesteśmy pewni, że piszemy kod jedynie pod Google Chrome, bądź Firefoksa, to możemy używać w obiektach jako nazw właściwości dowolnych ciągów, ponieważ tak mówi specyfikacja. Niestety to rzadki przywilej, chyba że piszemy np. aplikacje desktopowe, serwerowe, bądź jesteśmy Google. Lepiej więc wystrzegać się wszelkich słów kluczowych – włącznie z tymi zarezerwowanymi na przyszłość.

Jednocześnie należy pamiętać, że żadne słowo kluczowe nie może być nazwą zmiennej. Choć to akurat jest prostsze do zapamiętania. Tutaj również warto wystrzegać się słów kluczowych zarezerwowanych z myślą o przyszłości.

Zdjęcie autorstwa: David Ortez.

Podobne wpisy:

1. Obiektowy Javascript cz.1. – obiekt Twoim przyjacielem
2. Obiektowy JavaScript cz.2. – klasa sama w sobie
3. Obiektowy JavaScript i właściwości chronione – w poszukiwaniu Świętego Graala

JavaScript, mimo swojej pozornej prostoty, jest językiem o wielkich możliwościach. Przykładem tego są choćby biblioteki jakie w nim powstały – prototype, MooTools, czy jQuery. Moim zdaniem jego najważniejszą cechą jest elastyczność, która warunkuje (i warunkowana jest przez) wiele składowych – niezliczona ilość sposobów tworzenia obiektów, możliwość rozbudowywania już istniejących (nawet wbudowanych) oraz ich modyfikacji, operowania funkcjami, kontekstem, literały, scope, domknięcia, itd, itd. Dzięki tym cechom w JavaScriptcie, nawet mimo jego niecodziennemu paradygmatowi dziedziczenia prototypowego, można zapisać niemal każdą konstrukcję jaka w tych czasach jest możliwa do osiągnięcia w popularnych językach. Czy aby na pewno?

Otóż, nie. I jedną z najbardziej drażniących mnie w JavaScriptcie rzeczy jest brak modyfikatorów dostępu do właściwości obiektu. Rzecz jasna można uzyskać właściwości prywatne, jednak właściwości chronionych, najbardziej potrzebnych w wielu przypadkach, nie sposób wystrugać. Dla ścisłości – przez właściwość chronioną (protected) mam na myśli taką, która jest niedostępna z zewnątrz, jednakże w przypadku dziedziczenia dostępna jest dla klas pochodnych. Np (ależby było pięknie):

var Parent = function () {
	protected var secured = 'haha'; //byłoby pięknie :)
};
(new Parent()).secured; //-> undefined
 
var Child = function () {
	this.getSecured = function () { return secured; };
};
Child.prototype = new Parent();
 
(new Child()).getSecured(); //-> 'haha'

Ktoś może powiedzieć, że po prostu są niepotrzebne. Że nie umiem programować w tym paradygmacie. Możliwe. Nie znam stanowiska Douglasa Crockforda i żałuję że go o to nie spytałem (a miałem taką możliwość dzięki konferencji Front-Trends 2010 – przy okazji – Damian organizuje już następną Falsy Values (jak zawsze świetna nazwa :)). Domyślam się jednak, że on również uważa, że dostępne możliwości są wystarczające.

Mi jednak nigdy nie wystarczały. Może i z powodu niewiedzy oraz przyzwyczajeń, ale fakt jest faktem i kombinować trzeba. Podjąłem kilka prób, z czego jedna z nich zachowała się nawet na Githubie i wygląda obiecująco. Nie mam jednak czasu jej dokończyć. Poza tym to zawsze będą tylko marne atrapy, które gdzieś ograniczać będą tę wychwalaną przeze mnie elastyczność języka.

ECMAScript 5 na pomoc

Nim jednak o samym ES5, kilka słów o jego poprzedniku ES4. W latach kiedy jeszcze nie interesowałem się JavaScriptem na tyle by zagłębiać się w kwestie jego rozwoju, trwały prace nad czwartą wersją standardu. Niewiele już potrafię znaleźć informacji o pracach komitetu, który ma wyjątkowo zagmatwaną stronę i strukturę. Mogę się też mylić w kilku kwestiach, bo podczas wyszukiwania tych informacji czułem się jak archeolog. W każdym razie najciekawszym dokumentem jest ECMAScript 4^th Edition – Language Overview. Już po szybkim rzucie oka na jego zawartość widać, że zmiany miały być przełomowe. Klasy, dziedziczenie klasowe, interfejsy, kontrola typów, definicje typów, szablony, przestrzenie nazw, pakiety, więcej konstrukcji zaczerpniętych z języków funkcyjnych (lokalny scope (let), lambdy, wielokrotne zwracane wartości), generatory, iteratory, strict mode i wiele, wiele innych (nawet typ liczbowy związany z pieniędzmi). A wszystko to przy zachowaniu dotychczasowych możliwości. Moim zdaniem, jeśli standard nie zostałby zepsuty na etapie implementacji, to JavaScript byłby bliski mojemu ideałowi.

Historia potoczyła się jednak inaczej. Teoria spiskowa mówi, że Microsoft wstrzymał prace komitetu, ponieważ nie chciał dopuścić do zbytniego rozwoju JavaScriptu wobec rozwijanych przez siebie technologii. Nie mi oceniać czy to prawda, w każdym razie projekt został porzucony (trochę szczegółów). W tej chwili z listy funkcjonalności, które wymieniłem dostępnych jest w Firefoksie tylko kilka, aczkolwiek są to ciekawe rzeczy. Zostały one zawarte w czymś co nazwano JavaScript 1.7 i JavaScript 1.8.

Z popiołów ES4 wykluła się piąta wersja standardu, która rok temu została zatwierdzona (w tej chwili kończona jest wersja ES5.1 zawierająca poprawki). Wraz z nadejściem Firefoksa 4 wprowadzone przez nią funkcjonalności będą dostępne na zadowalającym poziomie w minimum trzech przeglądarkach (w Chrome’ie już zostały udostępnione, tak samo chyba w Operze 11), a według trochę wątpliwego (brak wspomnienia o ważnym strict mode) IE Test Center nawet w czterech. Można więc uznać, że standard został pomyślnie wdrożony.

Dwie twarze nowego standardu

Zaznaczam od razu, że to co napiszę poniżej jest jedynie moją opinią i w dodatku dość świeżą, ponieważ nie dane mi było jeszcze dokładnie przemyśleć część możliwości jakie daje ECMAScript 5. Jest jednak kilka, których wpływ na język jest dla mnie jasny. Są to natywny obiekt JSON, strict mode poprawiających niezliczoną ilość niedociągnięć JavaScriptu oraz metody Function.prototype.bind(), Object.keys() i związane z tablicami (Array.isArray(), czy Array.forEach()). Nie będę się rozpisywał na ten temat – polecam artykuł Johna Resiga oraz odświeżony Mozilla Developer Center (tu, tu, tu i tu). Z jednej strony to mało, szczególnie porównując to z listą, którą zamieściłem wcześniej, z drugiej strict mode sam w sobie jest przełomowy. Niby zmienia mało zauważalne zachowania, ale przyczynia się do ogromnej poprawy jakości kodu pisanego w JavaScriptcie.

Jednocześnie ECMAScript 5 wprowadza wiele rzeczy, co do których jestem przekonany słabiej bądź w stopniu wręcz ujemnym. Większość z nich znajduje się na liście nowych funkcjonalności w JavaScript 1.8.5 oraz w drugim artykule Johna Resiga. W skrócie – są to metody i konstrukcje rozszerzające możliwości obiektów. I o ile konstrukcje getterów i setterów uważam za przyzwoite, a nawet bardzo ciekawe, to rozwinięcie możliwości obiektów, co jest drugą częścią standardu, uważam za co najmniej brzydkie i dodatkowo mało przydatne.

W wielkim skrócie w tej chwili zyskujemy możliwość zamykania i zamrażania obiektów. Dodatkowo możemy zmieniać cechy ich atrybutów (czy są wyliczane podczas pracy z for in, modyfikowalne oraz czy ich cechy można zmieniać). Wszystko to prowadzi do sytuacji kiedy możemy tworzyć tzw. domoidy, czyli obiekty, które będą zachowywały się jak natywne DOMowe. Wszystko spoko, fajnie mieć takie możliwości, ale nie jest to killer feature jak niektórzy twierdzą. I nawet jeśli już wpadnie mi do głowy, że mogę zablokować możliwość zmiany wartości właściwości obiektu, to… to jest ohydne:

var obj = {};
Object.defineProperty(obj, 'value', {
	value: 'something',
	writable: false,
	enumerable: true,
	configurable: true
});

Nie jestem też przekonany co do doboru domyślnych wartości tych cech – wszystkie są równie false (tak więc w powyższym przykładzie możemy pominąć writable: false). Wszystkie metody które zostały wprowadzone do edycji cech atrybutów są tak samo toporne. Autorzy pomysłów czerpali chyba z pierwszej części nazwy języka JavaScript. Wydaje mi się, że postąpiono tak ze względu na wsteczną zgodność. Uważam, że mniejszym złem byłoby jednak wprowadzenie równolegle cukru składniowego (polskie określenie jest jak zawsze drętwe :), bo te metody okaleczają język. Pocieszający jest fakt, że według starego artykułu Johna Resiga o ECMAScript Harmony jest to tylko wstęp do głębszych zmian:

This means a couple things: First, you can forget a lot of what you learned about ECMAScript 4, previously. Many of the complicated concepts contained in the language have been tossed. Instead there is a considerable amount of effort going in to making sure that new features will be easily duplicable through other means.

For example, ECMAScript 3.1 provides a new method – called Object.freeze() – which allows you to pass in an object and “freeze” it, preventing it from being modified any further. This is a subset of the functionality that is needed to implement classes in ECMAScript 4 (classes are immutable).

Święty Graal

To by było na tyle wstępu :). Pora przejść do meritum tego wpisu. Kiedy pierwszy raz usłyszałem o cechach writable i enumerable, to pomyślałem, że jestem zbawiony. Właściwość będzie nieedytowalna i „niewyświetlalna” z „zewnątrz”, a ze „środka” będę mógł nią operować. Nic bardziej mylnego – z dość oczywistych powodów atrybut ten jest niezmienialny z każdego punktu. Bo jak odróżnić w JavaScriptcie „środek” od „zewnątrz”?

Trochę więc się podłamałem. Tyle nowych możliwości, ale właściwości chronionej obiektu, który może stać się pełnoprawnym prototypem swojego potomka nie da się uzyskać. W zasadzie jestem podłamany dalej, jednak kilka dni temu myśląc o getterach i setterach wpadłem na pewien pomysł. Od razu zaznaczam, że prawdopodobnie i tak nic nie wyjdzie z tej próby :). Że jest brzydka i nie wiem jeszcze czy da się opakować w coś ładniejszego. Że nie wiem też czy próba pozwala na kolejne dziedziczenie. W każdym razie. Proof of concept właściwości chronionej w JavaScriptcie:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

"use strict";
 
Object.extend = function (obj_orig, obj_new) {
    for (var i in obj_new) {
        var g = obj_new.__lookupGetter__(i),
			s = obj_new.__lookupSetter__(i);
 
        if (g || s) {
            if (g)
                obj_orig.__defineGetter__(i, g);
            if (s)
                obj_orig.__defineSetter__(i, s);
         } else
             obj_orig[i] = obj_new[i];
    }
    return obj_orig;
};
 
Object.clone = function (obj) {
	return Object.extend({}, obj);
};
 
 
var Animal = function (s, a) {
	var species;
	var age;
	var constructor = function (s, a) {
		species = s;
		age = a;
	};
	constructor(s, a);
 
	this.getSpecies = function () {
		return species;
	};
	this.getAge = function () {
		return age;
	};
	this.sayHello = function () {
		return 'Hello';
	};
 
	this.__access = {
		get species() {
			return species;
		},
		set species(val) {
			species = val;
		},
		get age() {
			return age;
		},
		set age(val) {
			age = val;
		},
		super: constructor
	};
};
var Kitten = function (a) {
	var parent = new Animal();
	var that = Object.extend(
		Object.extend(
			Object.clone(this), parent.__access
		), parent
	); //clone this?
	Object.extend(this, parent);
 
	that.super('Kitten', a);
 
	this.setAge = function (val) {
		that.age = val;
	};
 
	this.killedByGod = function () {
		that.age = 'Who cares? It\'s dead.';
	};
};
Kitten.prototype = new Animal(); //for the instanceof purpose only

Oraz użycie:

81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98

var animal = new Animal('Dog', 4);
console.log('animal.age: ' + animal.age); //-> undefined
console.log('animal.getSpecies(): ' + animal.getSpecies()); //-> 'Dog'
 
 
var kitten = new Kitten(0.5);
console.log('kitten.getSpecies(): ' + kitten.getSpecies()); //-> 'Kitten'
 
console.log('kitten.getAge(): ' + kitten.getAge()); //-> 0.5
kitten.setAge(1);
console.log('kitten.getAge(): ' + kitten.getAge()); //-> 1
 
kitten.killedByGod();
console.log('kitten.getAge(): ' + kitten.getAge()); //-> 'who cares?'
 
console.log('kitten.age: ' + kitten.age); //-> undefined
 
console.log('kitten instanceof Animal: ' + (kitten instanceof Animal));

Przykład działania w Google Chrome:

Co o tym sądzicie? Da się coś wystrugać?

Podobne wpisy:

1. Obiektowy Javascript cz.1. – obiekt Twoim przyjacielem
2. Obiektowy JavaScript cz.2. – klasa sama w sobie
3. Delegacja i funkcje generyczne w JavaScript

Do tego czteroczęściowego (jak zapowiem, to może napiszę :) artykułu natchnęło mnie szkolenie z zaawansowanego JavaScriptu które, w miniony weekend, zorganizował we Wrocławiu Damian Ferrante Wielgosik. Już na początku chciałbym mu podziękować za wiedzę, którą się podzielił, ponieważ przed szkoleniem byłbym wstanie napisać tylko część tego artykułu.

JavaScript to dziwoląg

Tego nie da się ukryć. JavaScript należy do wąskiej grupy języków z rodziny ECMAScriptu (JS, ActionScript, E4X), którą cechuje to, że ich obiektowość oparta jest na prototypach. Oznacza to, że w JavaScriptcie nie istnieje pojęcie klasy. Nie oznacza to jednak tego, że w JavaScriptcie nie da się programować obiektowo z wykorzystaniem np. konkretyzacji, dziedziczenia, czy właściwości prywatnych. Da się. Co więcej — da się uzyskać dużo więcej funkcjonalności klasycznego języka obiektowego, choć, o czym na sam koniec, niekoniecznie jest po co.

Obiekt

W języku z obiektowością klasową wypada zacząć od definicji klasy. Tak przynajmniej zaczynali autorzy książek, które czytałem. W przypadku JavaScriptu mielibyśmy jednak pewien problem, bo klas tutaj nie ma. Trzeba więc zacząć od utworzenia obiektu. Oto najprostszy:

var obj = {};
typeof obj; // -> "object"

Tak, to w JavaScriptcie jest najprostszy obiekt. Zadeklarowany w przykładzie jest pusty i dziedziczy po obiekcie Object. Możemy sprawdzić to za pomocą poniższego kodu (jak działa i co to znaczy, o tym później):

var obj = {};
obj.__count__; // -> 0, działa tylko w Firefoksie
obj.__proto__.constructor; // -> Object()

Obiekt możemy również utworzyć za pomocą konstruktora Object(). Nie jest to jednak sposób polecany, ponieważ… zmienną Object można nadpisać. Lepiej pozostać przy literałach obiektów, które są bezpieczniejsze i ładniejsze.

var obj = new Object(); // -> Object
Object = 5;
var obj2 = Object(); // ->  TypeError: Object is not a constructor

Właściwości obiektu

Nic nam jednak z pustego obiektu. Pora dodać do niego dane i metody. Możemy skorzystać ze składni literału obiektu:

var obj = {
	text: 'Jestem obiektem',
	saySth: function () {
		alert(this.text);
	}
};

Bądź stworzyć pusty obiekt i dodać mu właściwości:

var obj = {};
obj.text = 'Jestem obiektem';
obj.saySth = function () {
	alert(this.text);
};

W obu przypadkach efekt będzie ten sam. Kiedy wywołamy obj.saySth(); dostaniemy alerta z tekstem Jestem obiektem.

Jeszcze słowo wtrącenia o literałach. Trzeba uważać na przecinek po ostatniej właściwości. Firefox i chyba wszystkie normalne przeglądarki trzymają się specyfikacji ECMAScript 5 pkt 11.1.5 (bądź to specyfikacja trzyma się tych przeglądarek ;), a kochany IE6, który zawsze musi być inny („inny nie znaczy gorszy” w tym wypadku nie działa ;) trzyma się specyfikacji ECMAScript 3 pkt 11.1.5. Tak więc przecinek po ostatniej właściwości zostanie zaakceptowany przez przeglądarki z rodziny normalnych, zaś IE6 wywali cichaczem błąd. Nie wiem co prawda jak sprawa wygląda w IE7 i IE8, ale radzę po prostu tego przecinka nie stawiać. Koniec dygresji.

W Javie, czy PHP metoda obiektu jest czymś zupełnie innym niż jego właściwość. W JavaScriptcie metoda jest po prostu funkcją przypisaną do właściwości obiektu. Widać to najlepiej w trzeciej linii ostatniego przykładu: obj.saySth = function () {};. Wynika to z tego, że w JavaScriptcie funkcja też jest obiektem. Dzięki temu możemy ją przypisywać do zmiennych, zwracać w innych funkcjach, czy… wywoływać na niej metody. Ta właściwość JavaScriptu jest naprawdę potężna i myślę, że język ten sporo teraz zyskał w oczach osób lubiących Rubiego, Pythona, czy jakiś język funkcyjny :).

Uwaga na this

typeof obj.saySth; // -> "function"
var sayNothing = obj.saySth;
typeof sayNothing; // -> "function"
sayNothing(); // -> alert undefined

Z pierwszych trzech linii widać, że możemy sobie dowolnie operować funkcją. Czwarta może być zaskoczeniem. Dlaczego this.text === undefined? Zauważcie, że funkcja sayNothing nie została wywołana w kontekście obiektu obj, tylko w kontekście… no właśnie — czego? Żeby to sprawdzić dodajmy dwie linie kodu do poprzednich przykładów:

window.text = 'Jestem globalnym scopem';
sayNothing(); // -> alert "Jestem globalnym scopem"

Teraz widać, że funkcja sayNothing(); wywołana jest w globalnym kontekście. Możemy ją także wywołać w odpowiednim kontekście używając metody call() działającej na funkcji (tak jak pisałem wcześniej — funkcja też jest obiektem, więc ma też swoje metody):

sayNothing.call(obj); // -> alert "Jestem obiektem"

Więcej na ten temat u Ferrante w „this” w JavaScript.

Jeszcze trochę o obiektach

Do właściwości obiektu możemy się również dostać za pomocą operatora [], czyli w taki sposób jak do elementów tablicy. Jest to przydatne kiedy chcemy uzyskać właściwość, której nazwa trzymana jest w zmiennej:

var obj = { a: 'A', b: 'B', m: function () { return 'M'; } };
 
obj['a']; // -> "A"
var name = 'b';
obj[name]; // -> "B"
obj['m'](); // -> "M"

Po właściwościach obiektu można też iterować za pomocą konstrukcji for (i in obj). Trzeba jednak uważać, bo, w zależności od tego jakim obiektem dysponujemy, możemy dostać niespodziewane (przynajmniej na razie) rezultaty. Póki co jednak wystarczy nam:

var obj = { a: 'A', b: 'B', c: 'C', d: 'D' };
for (i in obj) {
	alert('obj[' + i + '] = ' + obj[i]);
}

Obiekty można też zagłębiać. Jest to własność oczywista, ale wypada dla jasności o niej wspomnieć.

var obj = {
	obj: {
		obj: {
			hidden: 'Zonk'
		}
	}
};
obj.obj.obj.hidden; // -> "Zonk"

Co dalej?

Samym obiektem programista żyć nie może. Klas jednak w JavaScripcie nie uświadczymy, trzeba więc wymyślić coś innego. Z pomocą przyjdą nam konstruktory obiektów, ale zrobią to dopiero w następnej części :).

Poza tym w trzeciej części mam zamiar napisać o prototypach, czyli JavaScriptowym dziedziczeniu. W czwartej chciałbym zebrać wszystko do kupy, pokazać może jakieś wzorce i napisać kilka uwag o programowaniu w JavaScriptcie. W zasadzie to uwagi mam już napisane, bo zacząłem od końca :D.

Druga część wpisu – Obiektowy JavaScript cz.2. – klasa sama w sobie.

Artykuł został także opublikowany na moim prywatnym blogu.

Podobne wpisy:

1. Obiektowy JavaScript cz.2. – klasa sama w sobie
2. Obiektowy JavaScript i właściwości chronione – w poszukiwaniu Świętego Graala
3. Delegacja i funkcje generyczne w JavaScript