Obiekt JSON vs singleton, Co może singleton czego nie może obiekt JSON Opcje

[pp-layouts]

Zrobiłem sobie klasę AJAX, będącą zestawem narzędzi i mającą jakieśtam swoje właściwości (do konfiguracji). Utworzyłem ją jako zwykły obiekt, będący zmienną globalną mniej więcej tak:

Kod

var AJAX = {
  property1 : null,
  property2 : null,
  method1 : function() {
    ...
  }
}

Odwołuję się do niej prosto: AJAX.method1(); . Komodo Edit daje prawidłowe podpowiedzi do właściwości i metod.
Co więcej, w środku utworzyłem więcej modułów JSON, tak że mogę odwoływać się do nich per AJAX.module1.method1().

Wszystko pięknie. Prawie dokładny odpowiednik klasy statycznej w PHP. Nawet lepiej, bo to klasa która może zawierać inne klasy. Moduł składający się z modułów. Git.

W takim razie po co używać singletonów? Co one mogą, czego nie może moduł JSON?

Zrobiłem pełną edycję poprzedniego posta, bo nikt chyba nie złapał o co mi w ogóle chodzi.



Ten post edytował pp-layouts 1.12.2009, 00:23:12

[pp-layouts]

Proszę, wytłumacz dokładniej, w jaki sposób klasa statyczna zajmuje więcej miejsca w pamięci. Czy kod metod niestatycznych nie zużywa miejsca w pamięci jeśli nie są użyte? Czyli jak, dopiero zaczynają używać miejsce po pierwszym użyciu?

A propos Twojego pierwszego posta, to pewnie wina przykładu, zbyt abstrakcyjny, może gdybyś zapodał na czymś bardziej konkretnym. Nie rozumiem też, co ma w ogóle JSON (a właściwie object literal, bo JSON wymaga, żeby nazwy właściwości pisać z użyciem cudzysłowów) do "this". This-a można używać odnosząc się do wnętrza literala (namespace-a), a można do instancji klasy, zależnie od kontekstu. To czy zapiszę klasę w formie funkcji, czy zapiszę ją jako obiekt OL - cóż, wydaje mi się, że to tylko kwestia zapisu, nie ma to chyba żadnych innych implikacji, bo próbowałem na dużych klasach tych 2 sposobów zapisu zamiennie i wydawały się działać dokładnie identycznie. Przy zapisie w OL może wystąpić niejednoznaczność "this". Ale tylko w przypadku kiedy nie przypisuje się bezpośrednio obiektu do prototypu. Wtedy w kontekście OL będzie oznaczać namespace, a w kontekście instancji tą instancję.

Co do metod i zmiennych prywatnych - to znów wydaje mi się sztuką dla sztuki, bo z tego co wiem, JavaScript tego po prostu nie obsługuje, ale można to wymusić - kosztem skomplikowania kodu. I znów z tego co wiem, dostępność zmiennych i metod ogranicza się dla ułatwienia życia, stąd umyka mi sens tej operacji. (Poza może very very defensive programming). Bo jeśli chodzi o ułatwienie życia developerom, to o wiele prostszy i wygodniejszy jest JSDoc, gdzie można opisać sobie klasy i dostępność keywordami takimi jak @class, @public, @private, @final itede.

Jak znajdę trochę czasu wolnego, muszę zrobić kiedyś trochę benchmarków różnych rozwiązań - zobaczymy w praktyce co jest szybsze i o ile.

Jak już mówimy o szybkości, zastanawia mnie też, czemu wszędzie używa się if (typeof(zmienna) == 'undefined') zamiast if (zmienna === undefined). Pierwsze wydaje mi się dużo wolniejsze, bo wymaga porównania napisów, a drugie odpala super szybką funkcję systemową, zbliżoną strukturalnie do isNan(). Wiem, że można złośliwie przypisać do undefined jakąś wartość, ale znów pojawia się pytanie - po co?

Dalej, jQuery używa lokalnych definicji undefined, które są === undefined. Czytałem, że to przyspiesza kod, ale czy na tyle znacząco, żeby używać tego poza frameworkiem? I czy aby jest to jeszcze aktualne dla nowych silników JS? (FF3.5, O10, Chrome 3)