Mozilla Hacks: ECMAScript 5 Strict Mode – tryb ścisły w ECMAScripcie 5

W tym odcinku tłumaczeń artykułów z Mozilla Hacks – notka Jeffa Waldena o trybie ścisłym w JavaScripcie. Jeff zajmuje się rozwojem SpiderMonkey, silnika JS Firefoksa.

Zarówno oryginalny artykuł, jak i to tłumaczenie dostępne są na licencji Creative Commons – Attribution Share-Alike v3.0.

ECMAScript 5 strict mode – tryb ścisły ES w Firefoksie 4

Programiści ze społeczności Mozilli znacząco usprawnili silnik JavaScriptu w Firefoksie 4. Wiele wysiłku włożyliśmy w zwiększenie wydajności, ale pracowaliśmy także nad nowymi możliwościami. W szczególności skupiliśmy się na ECMAScripcie 5, najnowszej wersji standardu będącego podstawą JavaScriptu.

Tryb ścisły (ang. strict) jest najbardziej interesującą nowością ECMAScriptu 5. Programiści mają możliwość skorzystania ze ściślejszego, bardziej ograniczonego wariantu JavaScriptu. Tryb ścisły nie jest tylko podzbiorem języka: ma celowo inną semantykę w porównaniu ze zwykłym kodem. Przeglądarki, które nie obsługują trybu ścisłego, będą uruchamiać kod w nim napisany w inny sposób niż przeglądarki tryb ścisły obsługujące – nie należy więc ślepo polegać na trybie ścisłym bez testowania (wykrywania) wsparcia istotnych aspektów tego trybu.

Kod z trybu ścisłego może współistnieć z kodem zwykłym, tak więc skrypty mogą przechodzić do tego trybu stopniowo. Tryb ścisły wyznacza drogę dla kolejnych edycji ECMAScriptu, w których nowy kod z określonym typem w atrybucie <script type="..."> najprawdopodobniej będzie uruchamiany właśnie w tym trybie.

Co takiego robi tryb ścisły? Po pierwsze, eliminuje niektóre „pułapki” starszych wersji języka – uniemożliwia stosowanie niewłaściwych konstrukcji, które do tej pory nie kończyły się jednak błędem. Po drugie, naprawia on błędy, które utrudniały silnikom JavaScriptu dokonywanie optymalizacji: kod działający w trybie ścisłym może być wykonywany szybciej niż identyczny kod zwykły. Firefox 4 ogólnie nie optymalizuje jeszcze kodu trybu ścisłego, ale kolejne wersje będą to robić. Po trzecie, tryb ścisły uniemożliwia stosowanie składni, która zostanie wykorzystana w kolejnych wersjach ECMAScriptu.

Włączanie trybu ścisłego

Tryb ścisły można włączyć dla całych skryptów lub konkretnych funkcji. Nie można go włączyć w blokach w nawiasach klamrowych ({}), wszelkie próby takiego jego wykorzystania spełzną na niczym. Kod w eval, procedury obsługi zdarzeń w atrybutach, ciągi znaków przekazane do setTimeout itp. są traktowane jako całe skrypty i można w nich włączyć tryb ścisły.

Tryb ścisły dla skryptów

Aby włączyć tryb ścisły dla całego skryptu, wystarczy wstawić przed pierwszym wyrażeniem w skrypcie następujący ciąg znaków: "use strict"; (ewentualnie 'use strict';).

// tryb ścisły dla całego skryptu
"use strict";
var v = "Cześć! Jestem skryptem trybu ścisłego!";

Uwaga: składnia ta ma pułapkę, na którą złapały się już duże witryny (Amazon #1, Amazon #2): nie można ślepo łączyć w jeden plik skryptów w różnych trybach. Rozpatrzmy przypadek skryptu trybu ścisłego połączonego ze zwykłym skryptem: cały połączony skrypt pracuje w trybie ścisłym! I odwrotnie, połączenie kodu zwykłego z kodem trybu ścisłego daje w efekcie kod w trybie zwykłym. Łączenie skryptów trybu ścisłego z innymi skryptami trybu ścisłego nie powoduje problemów, podobnie nie ma problemów z łączeniem skryptów trybu zwykłego z innymi skryptami trybu zwykłego. Tylko mieszanie skryptów zwykłych ze skryptami trybu ścisłego jest problematyczne.

Tryb ścisły dla funkcji

Aby włączyć tryb ścisły na poziomie funkcji, należy jako pierwsze wyrażenie w funkcji podać ciąg znaków: "use strict"; (lub 'use strict';) – w ciele funkcji przed jakimikolwiek innymi wyrażeniami.

function strict()
{
  // tryb ścisły na poziomie funkcji
  'use strict';
  function nested() { return "Ja też"; }
  return "Cześć! Jestem funkcją trybu ścisłego! " + nested();
}
function notStrict() { return "A ja nie."; }

Zmiany w trybie ścisłym

Tryb ścisły zmienia zarówno składnię, jak i zachowanie w czasie pracy skryptów. Zmiany te można ogólnie podzielić na kilka kategorii: zmiany przekształcające pomyłki w błędy (takie jak błędy składni lub błędy w czasie pracy), zmiany upraszczające wyliczanie konkretnej zmiennej dla danej nazwy, zmiany upraszczające eval i arguments, zmiany ułatwiające pisanie w „bezpiecznym” JavaScripcie i zmiany przygotowujące do ECMAScript do dalszego rozwoju.

Pomyłki jako błędy

Tryb ścisły traktuje jako błąd stosowanie kodu, który wcześniej był akceptowany, mimo że zwykle był pomyłką. JavaScript zaprojektowano tak, żeby był łatwy do nauki przez początkujących programistów, przez co często operacje, które powinny być błędami, miały nadawane znaczenie nie powodujące błędu. Czasami rozwiązywało to dany problem, ale często zamieniało małe problemy na znacznie większe w przyszłości. Tryb ścisły traktuje tego rodzaju pomyłki jako faktyczne błędy, pozwalając na ich szybkie wykrycie i naprawę.

Po pierwsze, tryb ścisły uniemożliwia przypadkowe tworzenie zmiennych globalnych. Dotychczas zrobienie np. literówki w nazwie zmiennej przy przypisaniu tworzyły
nową własność obiektu globalnego i pozwalało na dalszą „pracę” (ale błąd taki mógł się ujawnić później, szczególnie w bardziej współczesnym kodzie w JS).
Przypisania, które dotychczas omyłkowo tworzyły globalne zmienne, w trybie ścisłym wyrzucają wyjątki. W poniższym kodzie próbujemy przypisać wartość zmiennej zmienna, ale omyłkowo zrobiliśmy w jej nazwie literówkę:

"use strict";
zmeinna = 17; // wyrzuca wyjątek ReferenceError

Po drugie, w trybie ścisłym przypisania, które w trybie zwykłym skończyłyby się cichym niepowodzeniem, również wyrzucą wyjątki. Przykładowo, NaN jest globalną zmienną tylko do odczytu. W dotychczasowym kodzie przypisanie czegokolwiek do NaN nic nie robi; programista nie dostaje żadnej informacji o błędzie, a wykonywanie skryptu nie jest przerywane. W trybie ścisłym natomiast takie przypisanie wartości do NaN kończy się wyrzuceniem wyjątku. Każde przypisanie, które w trybie zwykłym kończy się cichym niepowodzeniem, spowoduje wyrzucenie wyjątku w trybie ścisłym:

"use strict";
NaN = 42; // wyrzuca wyjątek TypeError
var obj = { get x() { return 17; } };
obj.x = 5; // wyrzuca wyjątek TypeError
var fixed = {};
Object.preventExtensions(fixed);
fixed.newProp = "ohai"; // wyrzuca wyjątek TypeError

Po trzecie, w trybie ścisłym próba usunięcia nieusuwalnej własności również zakończy się wyrzuceniem wyjątku (wcześniej próby takie po prostu nie odniosłyby żadnego skutku, ale nie przerwałyby programu):

"use strict";
delete Object.prototype; // wyrzuca wyjątek TypeError

Po czwarte, tryb ścisły wymaga, by wszystkie nazwy własności w literale obiektu były unikalne. W tradycyjnym kodzie mogą w literale wystąpić własności o zduplikowanych nazwach, przy czym ostatnia z nich określi ostateczną wartość własności. Ale skoro tylko ostatnia z nich ma znaczenie, pozwalanie na taką duplikację jest po prostu wektorem dla kolejnych błędów, w sytuacji modyfikacji kodu, które miały zmienić wartość własności, ale zmieniły przypisanie wartości w literale, które nie było ostatnim. Zduplikowane nazwy własności stanowią błąd składni w trybie ścisłym:

"use strict";
var o = { p: 1, p: 2 }; // !!! błąd składni

Po piąte, tryb ścisły wymaga, by wszystkie argumenty danej funkcji miały unikalne nazwy. W dotychczasowym kodzie ostatni ze zduplikowanych argumentów przesłaniał poprzednie o tej samej nazwie. Były one wciąż dostępne poprzez arguments[i], nie były więc nieosiągalne. Przesłanianie takie nie ma jednak wiele sensu i zwykle jest niepożądane (często jest to po prostu np. literówka), tak więc w kodzie w trybie ścisłym zduplikowane nazwy argumentów to błąd składni:

function sum(a, a, c) // !!! błąd składni
{
  "use strict";
  return a + b + c; // wynik niezgodny z zamierzeniem, jeśliby ten kod się wykonał
}

Po szóste, niedozwolone jest stosowanie w trybie ścisłym składni ósemkowej. Składnia używająca liczb w systemie ósemkowym nie jest częścią standardu ECMAScript, ale była szeroko stosowana przez przeglądarki – wszystkie liczby poprzedzone zerem traktowane były jako liczby systemu ósemkowego: 0644 === 420, a "45" === "%". Niedoświadczeni programiści mogli czasem myśleć, że początkowe zero nie ma znaczenia, więc mogli go używać do wyrównania zapisu liczb — w efekcie zmieniało to znaczenie tej liczby! Składnia ósemkowa jest rzadko przydatna, potencjalnie powoduje problemy, tak więc każde zastosowanie składni ósemkowej w trybie ścisłym jest błędem składni:

"use strict";
var sum = 015 + // !!! błąd składni
          197 +
          142;

Uproszczenie wykorzystania zmiennych

Tryb ścisły upraszcza sposób, w jaki nazwy zmienych mapowane są do konkretnych definicji w kodzie. Wiele optymalizacji kompilatorów opiera się o możliwość określenia, że konkretna zmienna jest przechowywana w konkretnym miejscu: ma to krytyczne znaczenie dla pełnej optymalizacji kodu JavaScript. W JS proste mapowanie nazwy zmiennej do jej definicji jest niemożliwe, dopóki kod nie zostanie uruchomiony. W trybie ścisłym usunięta została większość przypadków, w których mogło tak się dziać, kompilator może więc teraz potencjalnie lepiej optymalizować taki kod.

Po pierwsze, w trybie ścisłym niedozwolone jest korzystanie ze słowa kluczowego with. Kłopot z with polega na tym, że każda nazwa wewnątrz tej sekcji może być mapowana albo do własności przekazanego obiektu, albo do zmiennej w otaczającym kodzie. Może się to także zmieniać w trakcie wykonywania kodu – nie jest więc możliwe określenie tego z wyprzedzeniem. Kod w trybie ścisłym traktuje with jako błąd składni, nie ma więc zagrożenia, że nazwa w sekcji with będzie się odwoływać podczas wykonywania skryptu do nieznanego miejsca:

"use strict";
var x = 17;
with (obj) // !!! błąd składni
{
  // Gdyby to nie był tryb ścisły, czy byłoby to var x,
  // czy może jednak obj.x?  W ogólnym przypadku
  // nie można tego określić przed wykonaniem kodu,
  // co uniemożliwia optymalizację.
  x;
}

Alternatywą dla with jest po prostu przypisanie obiektu do zmiennej, a następnie korzystanie z własności tej zmiennej.

Po drugie, wykonanie poprzez eval kodu trybu ścisłego nie wprowadza nowych zmiennych do otaczającego kodu. W tradycyjnym kodzie eval("var x;") wstawia zmienną x do otaczającej funkcji lub zasięgu globalnego. Oznacza to, że w funkcji zawierającej wywołanie eval każda nazwa, która nie odwołuje się do argumentu lub zmiennej lokalnej, musi być zmapowna do konkretnej definicji w trakcie wykonywania (ponieważ to eval mogłoby inaczej wprowadzić nową zmienną, która przykryłaby zmienną zewnętrzną). W trybie ścisłym eval tworzy zmienne tylko w obrębie wyliczanego kodu, tak więc nie może zmodyfikować zmiennej zewnętrznej ani lokalnej:

var x = 17;
var evalX = eval("'use strict'; var x = 42; x");
assert(x === 17);
assert(evalX === 42);

Ponadto, jeśli funkcja eval jest wywoływana przez wyrażenie postaci eval(...) w trybie ścisłym, wyliczany kod również zostanie uruchomiony w trybie ścisłym. Kod ten może otwarcie zadeklerować tryb ścisły, ale nie ma takiej potrzeby

function strict1(str)
{
  "use strict";
  return eval(str); // str będzie traktowany jako kod trybu ścisłego
}
function strict2(f, str)
{
  "use strict";
  return f(str); // nie eval(...): str będzie w trybie ścisłym, jeśli zadeklaruje tryb ścisły
}
function nonstrict(str)
{
  return eval(str); // str będzie w trybie ścisłym, jeśli zadeklaruje tryb ścisły
}
strict1("'Tryb ścisły!'");
strict1("'use strict'; 'Tryb ścisły!'");
strict2(eval, "'Tryb zwykły'");
strict2(eval, "'use strict'; 'Tryb ścisły!'");
nonstrict("'Tryb zwykły.'");
nonstrict("'use strict'; 'Tryb ścisły!'");

Po trzecie, tryb ścisły uniemożliwa usuwanie zwykłych nazw. Tak więc nazwy w eval trybu ścisłego zachowują się identycznie jak nazwy w kodzie trybu ścisłego nie będącego wynikiem eval. delete nazwa w trybie ścisłym to błąd składni:

"use strict";
eval("var x; delete x;"); // !!! błąd składni

Uproszczenie eval i arguments

W trybie ścisłym arguments i eval są mniej „dziwacznie magiczne”. Oba te wyrażenia w trybie zwykłym wiążą się z nietypowym zachowaniem: zmienianie, usuwanie lub modyfikacja wartości wiązania eval, dostęp do arguments po aliasach dla jego indeksowanych własności. W trybie ścisłym poczyniono pewne kroki ku traktowaniu eval i arguments jako słów kluczowych, choć kompletna poprawka dostępna będzie dopiero w późniejszej edycji ECMAScriptu.

Po pierwsze, nazwy eval i arguments nie mogą być dowiązywane ani przypisywane w składni języka. Wszelkie tego rodzaju próby kończą się błędem składni:

"use strict";
eval = 17;
arguments++;
++eval;
var obj = { set p(arguments) { } };
var eval;
try { } catch (arguments) { }
function x(eval) { }
function arguments() { }
var y = function eval() { };
var f = new Function("arguments", "'use strict'; return 17;");

Po drugie, tryb ścisły nie aliasuje własności obiektów arguments. W zwykłym kodzie, wewnątrz funkcji o pierwszym argumencie arg przypisanie arg wartości zmienia także wartość arguments[0] i vice versa (chyba że nie podano argumentów lub arguments[0] zostało usunięte). Obiekty arguments dla funkcji trybu ścisłego przechowują pierwotne argumenty z chwili wywołania funkcji. arguments[i] nie śledzi wartości odpowiadającego mu argumentu nazwanego, jak również argument nazwany nie śledzi wartości odpowiadającego mu arguments[i].

function f(a)
{
  "use strict";
  a = 42;
  return [a, arguments[0]];
}
var pair = f(17);
assert(pair[0] === 42);
assert(pair[1] === 17);

Po trzecie, własność arguments.callee nie jest już wspierana. W trybie zwykłym arguments.callee odnosi się
do otaczającej funkcji. Ten przypadek użycia callee nie jest potrzebny: po prostu nazwij funkcję otaczającą! Co więcej, arguments.callee znacząco osłabia możliwości optymalizacji, takie jak zamiana funkcji zwykłych na kod inline, ponieważ musi być możliwość odwołania się do właściwej funkcji przez arguments.callee (a po przekształceniu funkcji na kod inline nie byłoby się przecież do czego odwołać). W funkcjach trybu ścisłego arguments.callee jest nieusuwalną własnością, która wyrzuca wyjątek przy próbie odczytu lub ustawienia:

"use strict";
var f = function() { return arguments.callee; };
f(); // wyrzuca wyjątek TypeError

„Zabezpieczanie” JavaScriptu

Tryb ścisły ułatwia pisanie „bezpiecznego” JavaScriptu. Niektóre witryny udostępniają użytkownikom możliwość pisania JavaScriptu, który będzie uruchamiany przez te witryny dla innych użytkowników. JavaScript w przeglądarkach ma dostęp do pewnych prywatnych informacji użytkownika, musi więc być częściowo przetworzony przed uruchomieniem, by ocenzurować dostęp do zakazanych funkcji. Elastyczność JavaScriptu praktycznie uniemożliwia takie zabezpieczenie, o ile nie stosuje się wielu punktów kontroli podczas wykonywania. Niektóre funkcje języka są tak wszechobecne, że punktu kontroli podczas wykonywania wiążą się z dużymi kosztami po stronie wydajności. Kilka usprawnień z trybu ścisłego oraz wymóg, by kod dostarczony przez użytkownika był w trybie ścisłym i mógł być wywołany tylko w konkretny sposób, znacząco ogranicza potrzebę stosowania kontroli podczas wykonywania.

Po pierwsze, własność przekazana do funkcji jako this w trybie ścisły nie jest pakowana do obiektu. Dla zwykłej funkcji this jest zawsze obiektem: obiektem dostarczonym, jeśli wywołano funkcję z this ustawionym na obiekt, opakowaną w obiekt wartość prostą, jeśli funkcję wywołano z this o wartości typu boolean, string lub number, lub obiektem globalnym, jeśli wywołano funkcję z this o wartości undefined lub null. (Do określenia konkretnego this używa się metod call, apply i bind). Automatyczne opakowywanie wiąże się ze stratą wydajności, natomiast udostępnianie obiektu globalnego w przeglądarkach jest zagrożeniem bezpieczeństwa, ponieważ globalny obiekt pozwala na dostęp do funkcjonalności, które „bezpieczne” środowiska JavaScript powinny ukrywać. Tak też w funkcjach trybu ścisłego przekazane this nie jest zmieniane:

"use strict";
function fun() { return this; }
assert(fun() === undefined);
assert(fun.call(2) === 2);
assert(fun.apply(null) === null);
assert(fun.call(undefined) === undefined);
assert(fun.bind(true)() === true);

(Na marginesie, metody wbudowane również nie opakowują już this, jeśli ma ono wartość null lub undefined. [Ta zmiana jest niezależna od trybu ścisłego; umotywowana jest jednak tymi samymi obawami o udostępnianie obiektu globalnego]. Historycznie, przekazywanie null lub undefined do metod wbudowanych, takich jak Array.prototype.sort(), działałoby tak, jak przekazywanie obiektu globalnego.
Teraz przekazanie którejkolwiek z tych wartości jako this do większości metod wbudowanych spowoduje wyrzucenie wyjątku TypeError. Wartości logiczne, liczby i ciągi znaków wciąż są opakowywane przez te metody: zmienione zostało ich zachowanie tylko w tych przypadkach, w których modyfikowany byłļy obiekt globalny).

Po drugie, w trybie ścisłym nie jest już możliwe przechodzenie po stosie wywołań JavaScriptu za pomocą szeroko dotąd implementowanych rozszerzeń ECMAScriptu. W zwykłym kodzie dzięki tym rozszerzeniom, kiedy funkcja fun jest wykonywana, fun.caller odnosi się do funkcji, która ostatnio wywołała fun, a fun.arguments to obiekt arguments dla tamtego wywołana fun. Oba te rozszerzenia sprawiają problemy dla „bezpiecznego” JavaScriptu, ponieważ pozwalają na dostęp do funkcji uprzywilejowanych (ang. privileged) i ich (potencjalnie niezabezpieczonych) argumentów. Jeśli fun jest funkcją trybu ścisłego, zarówno fun.caller, jak i fun.arguments są nieusuwalnymi własnościami, które wyrzucają wyjątki przy próbie ustawienia lub odczytania:

function f()
{
  "use strict";
  f.caller;    // wyrzuca wyjątek TypeError
  f.arguments; // wyrzuca wyjątek TypeError
}
function privilegedInvoker()
{
  return restricted();
}
privilegedInvoker();

Po trzecie, arguments dla funkcji trybu ścisłego nie pozwala już na dostęp do zmiennych wywołania odpowiedniej funkcji. W niektórych starych implementacjach ECMAScriptu arguments.caller był obiektem, którego własności były aliasami zmiennych tej funkcji. Jest to zagrożenie bezpieczeństwa ponieważ uniemożłiwia chowanie wartości uprzywilejowanych poprzez abstrakcję funkcji, utrudnia także większość optymalizacji. Z tego powodu żadna współczesna przeglądarka nie implementuje tej własności. Z racji jednak swej dawnej funkcjonalności, arguments.caller dla funkcji trybu ścisłego również jest nieusuwalną własnością, która wyrzuca wyjątki przy próbie ustawienia lub odczytania:

"use strict";
function fun(a, b)
{
  "use strict";
  var v = 12;
  return arguments.caller; // wyrzuca wyjątek TypeError
}
fun(1, 2); // nie ujawnia v (ani a, ani b)

Wyznaczenie drogi dla kolejnych wersji ECMAScriptu

Kolejne wersje ECMAScriptu najprawdopodobniej wprowadzą nową składnię, a tryb ścisły w ECMAScript 5 wprowadza niektóre ograniczenia, żeby ułatwić przejście
do tych nowych wersji. Łatwiej będzie wprowadzić niektóre zmiany, jeśli podstawy tych zmian są zabezpieczone przed wykorzystaniem w trybie ścisłym.

Po pierwsze, w trybie ścisłym pewne identyfikatory zostały zarezerwowanymi słowami kluczowymi. Są to: implements, interface, let, package, private, protected, public, static i yield. W trybie ścisłym nie można ich używać do określania nazw zmiennych ani argumentów. Zastrzeżenie specyficzne dla Mozilli: jeśli twój kod jest w JS 1.7 lub nowszym (jest to kod tzw. chromu programu albo kod z właściwą wartością atrybutu <script type="">) i jest kodem trybu ścisłego, let i yield mają funkcjonalność taką, jaką miały w chwili ich pierwszego pojawienia się w Gecko. Kod trybu ścisłego na WWW załadowany zwykłym znacznikiem <script src=""> albo <script>...</script> nie może używać let/yield jako identyfikatorów.

Po drugie, tryb ścisły nie pozwala na deklarowanie funkcji poza najwyższym poziomem skryptu i funkcji. W zwykłym trybie w przeglądarkach deklaracje funkcji są dozwolone wszędzie. Nie jest to część ES5! Jest to rozszerzenie składni o niekompatybilnej między przeglądarkami semantyce. W kolejnych edycjach ECMAScriptu można liczyć na określenie nowej semantyki dla deklaracji funkcji poza najwyższym poziomem skryptu/funkcji. Zabronienie stosowania takich deklaracji w trybie ścisłym oczyszcza pole kolejnym wersjom ECMAScriptu do określenia ich zachowania w tej sytuacji:

"use strict";
if (true)
{
  function f() { } // !!! błąd składni
  f();
}
for (var i = 0; i < 5; i++)
{
  function f2() { } // !!! błąd składni
  f2();
}
function baz() // poprawne
{
  function eit() { } // również poprawne
}

Zabronienie deklarowania funkcji poza najwyższym poziomem nie wiąże się formalnie z trybem ścisłym, ponieważ takie deklaracje są rozszerzeniem JS. Jednakże taka jest rekomendacja komitetu ECMAScript i przeglądarki tak będą to implementować.

Tryb ścisły w przeglądarkach

Firefox 4 jest pierwszą przeglądarką, która całkowicie implementuje tryb ścisły. Silnik Nitro znany z przeglądarek WebKit lada moment powinien do Firefoksa dołączyć – wsparcie dla trybu ścisłego jest w nim teraz prawie kompletne. W Chrome także rozpoczęto prace nad implementacją tego trybu. Internet Explorer i Opera są w tyle i nie rozpoczęły jeszcze implementacji trybu ścisłego – jeśli Wam zależy, próbujcie przekonać autorów tych przeglądarek do wprodzenia tego trybu także i u nich.

Przeglądarki nie implementują trybu ścisłego niezawodnie – nie należy więc na nim ślepo polegać. Tryb ścisły zmienia znaczenie kodu. Opieranie się na tych zmianach spowoduje błędy przy wykonywaniu kodu napisanego dla trybu ścisłego w przeglądarkach go nie wspierających. Należy zachować ostrożność przy stosowaniu tego trybu, a opieranie się na nim warto wzmocnić testami, które sprawdzają, czy istotne dla nas funkcjonalności trybu ścisłego są zaimplementowane.

Aby sprawdzić tryb ścisły, zainstaluj najnowszą conocną kompilację Firefoksa i poeksperymentuj. Pamiętaj też o ograniczeniach trybu ścisłego podczas pisania nowego i modyfikacji istniejącego kodu (dla bezpieczeństwa jednak najlepiej wstrzymać się ze stosowaniem trybu ścisłego w środowisku produkcyjnym, dopóki nie jest on dostępny w innych przeglądarkach).


Aktualizacje artykułu:

  • poprawiłem dane autora oryginalnego tekstu – jest nim Jeff Walden. Chris Heilmann tylko opublikował ten artykuł na MozHacks.

2 responses to “Mozilla Hacks: ECMAScript 5 Strict Mode – tryb ścisły w ECMAScripcie 5

  1. Pingback: Tweets that mention Mozilla Hacks: ECMAScript 5 Strict Mode – tryb ścisły w ECMAScripcie 5 « marcoos.techblog -- Topsy.com

  2. Pingback: Nowe podejście do obiektów w ECMAScript 5. Deskryptory własności. « marcoos.techblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

MDN

Better JavaScript docs for a better Web on MDN

Archiwum

%d bloggers like this: