Add IT translation

Author: Marco Trulla

.gitignore

@@ -14,6 +14,7 @@
 /site/ja
 /site/es
 /site/zhtw
+/site/it
 *.md~
 *.src.md
 *.DS_store

doc/it/array/constructor.md

@@ -0,0 +1,34 @@
+## Il costruttore `Array`
+
+Dato che il costruttore `Array` è ambiguo riguardo a come esso gestisca i suoi
+parametri, si consiglia calorosamente di usare l'array letterale (notazione `[]`)
+quando si creano array.
+
+    [1, 2, 3]; // Risultato: [1, 2, 3]
+    new Array(1, 2, 3); // Risultato: [1, 2, 3]
+
+    [3]; // Risultato: [3]
+    new Array(3); // Risultato: []
+    new Array('3') // Risultato: ['3']
+
+Nei casi in cui c'è solo un argomento passato al costruttore `Array` e quando
+l'argomento è un `Number`, il costruttore ritornerà un nuovo array *frammentato*
+con la proprietà `length` impostata al valore dell'argomento. Si noti
+che in questo modo **solo** la proprietà `length` del nuovo array verrà impostata,
+mentre gli indici dell'array non verranno inizializzati.
+
+    var arr = new Array(3);
+    arr[1]; // undefined
+    1 in arr; // false, l'indice non è stato impostato
+
+Essere in grado di impostare la lunghezza dell'array in anticipo è utile soltanto
+in poche situazioni, come ad esempio la ripetizione di una stringa, nel cui caso
+si eviterebbe l'uso di un ciclo.
+
+    new Array(count + 1).join(stringToRepeat);
+
+### In conclusione
+
+I letterali sono da preferirsi al costruttore Array. Sono più concisi, hanno una
+sintassi più chiara ed incrementano la leggibilità del codice.
+

doc/it/array/general.md

@@ -0,0 +1,62 @@
+## Iterazione e proprietà degli Array
+
+Sebbene gli array in JavaScript siano oggetti, non ci sono valide ragioni
+per usare il ciclo [`for in`](#object.forinloop). Infatti, ci sono varie
+buone ragioni per **evitare** l'utilizzo di `for in` con gli array.
+
+> **Nota:** gli array in JavaScript **non** sono *array associativi*. JavaScript
+> ha solo [oggetti](#object.general) per mappare chiavi con valori. E mentre
+> gli array **preservano** il loro ordine, gli oggetti **non lo fanno**.
+
+Dato che il ciclo `for in` enumera tutte le proprietà che sono presenti nella
+catena di prototipi, e dal momento che il solo modo per escludere queste
+proprietà è quello di usare [`hasOwnProperty`](#object.hasownproperty),
+esso è già **venti volte** più lento di un normale ciclo `for`.
+
+### Iterazione
+
+Per poter ottenere la miglior performance durante l'iterazione degli array,
+è meglio usare il classico ciclo `for`.
+
+    var list = [1, 2, 3, 4, 5, ...... 100000000];
+    for(var i = 0, l = list.length; i < l; i++) {
+        console.log(list[i]);
+    }
+
+In questo esempio c'è un ulteriore particolare da notare, che è il caching
+della lunghezza dell'array tramite `l = list.length`.
+
+Sebbene la proprietà `length` sia definita nell'array stesso, c'è ancora un
+sovraccarico di lavoro dato dal fatto che deve essere ricercata ad ogni
+iterazione del ciclo. E mentre i motori JavaScript recenti **potrebbero**
+applicare delle ottimizzazioni in questo caso, non c'è modo di dire se il
+codice verrà eseguito su uno di questi nuovi motori oppure no.
+
+Infatti, l'omissione della parte di caching può risultare in un ciclo eseguito
+soltanto alla **metà della velocità** con cui potrebbe essere eseguito facendo
+il caching della lunghezza.
+
+### La proprietà `length`
+
+Mentre il *getter* della proprietà `length` ritorna semplicemente il numero di
+elementi che sono contenuti nell'array, il *setter* può essere usato per
+**troncare** l'array.
+
+    var foo = [1, 2, 3, 4, 5, 6];
+    foo.length = 3;
+    foo; // [1, 2, 3]
+
+    foo.length = 6;
+    foo.push(4);
+    foo; // [1, 2, 3, undefined, undefined, undefined, 4]
+
+Assegnando una lunghezza più piccola si tronca l'array. Incrementandola si
+crea un array frammentato.
+
+### In conclusione
+
+Per la miglior performance, si raccomanda di usare sempre il ciclo `for`
+classico e fare il caching della proprietà `length`. L'uso di `for in` su di
+un array è segno di un codice scritto male che è suscettibile a bug e pessima
+performance.
+

doc/it/core/delete.md

@@ -0,0 +1,90 @@
+## L'operatore `delete`
+
+In breve, è *impossibile* eliminare variabili globali, funzioni e qualche
+altra cosa in JavaScript che ha l'attributo `DontDelete` impostato.
+
+### Codice globale e codice funzione
+
+Quando una variabile o una funzione viene definita in un scope globale o
+[funzione](#function.scopes), essa è una proprietà dell'oggetto Activation
+o dell'oggetto Global. Queste proprietà hanno un set di attributi, tra i quali
+`DontDelete`. Dichiarazioni di variabile o funzione nel codice globale o
+funzione, creano sempre proprietà con `DontDelete`, e quindi non possono essere
+eliminate.
+
+    // variabile globale:
+    var a = 1; // DontDelete è impostato
+    delete a; // false
+    a; // 1
+
+    // funzione normale:
+    function f() {} // DontDelete è impostato
+    delete f; // false
+    typeof f; // "function"
+
+    // la riassegnazione non aiuta:
+    f = 1;
+    delete f; // false
+    f; // 1
+
+### Proprietà esplicite
+
+Proprietà esplicitamente impostate possono essere eliminate normalmente.
+
+    // proprietà impostata esplicitamente:
+    var obj = {x: 1};
+    obj.y = 2;
+    delete obj.x; // true
+    delete obj.y; // true
+    obj.x; // undefined
+    obj.y; // undefined
+
+Nel codice qui sopra, `obj.x` e `obj.y` possono essere eliminate perché
+non hanno l'attributo `DontDelete`. Ecco perché anche l'esempio seguente
+funziona.
+
+    // questo funziona, tranne che per IE:
+    var GLOBAL_OBJECT = this;
+    GLOBAL_OBJECT.a = 1;
+    a === GLOBAL_OBJECT.a; // true - solo una variabile globale
+    delete GLOBAL_OBJECT.a; // true
+    GLOBAL_OBJECT.a; // undefined
+
+Qui usiamo un trucco per eliminare `a`. [`this`](#function.this) qui fa
+riferimento all'oggetto Global e noi dichiariamo esplicitamente la
+variabile `a` come sua proprietà, il che ci permette di eliminarla.
+
+IE (almeno 6-8) ha alcuni bug, quindi il codice precedente non funziona.
+
+### Argomenti funzione e proprietà interne
+
+Anche i normali argomenti delle funzioni, gli
+[oggetti `arguments`](#function.arguments) e le proprietà interne hanno
+`DontDelete` impostato.
+
+    // argomenti funzione e proprietà:
+    (function (x) {
+
+      delete arguments; // false
+      typeof arguments; // "object"
+
+      delete x; // false
+      x; // 1
+
+      function f(){}
+      delete f.length; // false
+      typeof f.length; // "number"
+
+    })(1);
+
+### Oggetti non nativi (host)
+
+Il comportamento dell'operatore `delete` può essere inaspettato con gli oggetti
+non nativi. A causa delle specifiche, agli oggetti non nativi è permesso di
+implementare qualsiasi tipo di funzionalità.
+
+### In conclusione
+
+L'operatore `delete` spesso ha un comportamento inaspettato e può solo essere
+usato con sicurezza per eliminare proprietà esplicitamente impostate in oggetti
+normali.

doc/it/core/eval.md

@@ -0,0 +1,50 @@
+## Perché non usare `eval`
+
+La funzione `eval` eseguirà una stringa di codice JavaScript nello scope locale.
+
+    var foo = 1;
+    function test() {
+        var foo = 2;
+        eval('foo = 3');
+        return foo;
+    }
+    test(); // 3
+    foo; // 1
+
+Comunque, `eval` esegue solo nello scope locale quando viene chiamata
+direttamente *e* quando il nome della funzione chiamata è `eval`.
+
+    var foo = 1;
+    function test() {
+        var foo = 2;
+        var bar = eval;
+        bar('foo = 3');
+        return foo;
+    }
+    test(); // 2
+    foo; // 3
+
+L'uso di `eval` dovrebbe essere evitato. Il 99.9% dei suoi "utilizzi" può
+essere ottenuto **senza** di essa.
+
+### `eval` sotto mentite spoglie
+
+Le [funzioni di timeout](#other.timeouts) `setTimeout` e `setInterval` possono
+entrambe accettare una stringa come loro primo argomento. Questa stringa verrà
+**sempre** eseguita nello scope globale dato che `eval` non viene chiamato
+direttamente in questo caso.
+
+### Problemi di sicurezza
+
+`eval` è anche un problema di sicurezza, perché essa esegue **qualsiasi**
+codice le viene passato. Non si dovrebbe **mai** usare con stringhe di origine
+sconosciuta o inaffidabile.
+
+### In conclusione
+
+`eval` non dovrebbe mai essere usata. Qualsiasi codice che ne faccia uso dovrebbe
+essere messo in discussione sotto l'aspetto della funzionalità, della performance
+e della sicurezza. Se qualcosa richiede `eval` per poter funzionare, allora **non**
+dovrebbe essere usato in primo luogo, ma si dovrebbe prevedere una
+*miglior progettazione* che non richieda l'uso di `eval`.
+

doc/it/core/semicolon.md

@@ -0,0 +1,120 @@
+## Inserimento automatico dei punti-e-virgola
+
+Sebbene JavaScript utilizzi lo stile di sintassi del C, esso **non**
+obbliga l'uso dei punti-e-virgola nel codice sorgente, perciò è possibile
+ometterli.
+
+Detto questo, JavaScript non è un linguaggio che fa a meno dei punti-e-virgola.
+Infatti, esso necessita di punti-e-virgola per poter comprendere il codice
+sorgente. Quindi, il parser del JavaScript li inserisce **automaticamente**
+ogni volta che incontra un errore di analisi dato dalla mancanza di un
+punto-e-virgola.
+
+    var foo = function() {
+    } // errore di analisi, atteso punto-e-virgola
+    test()
+
+Quindi avviene l'inserimento, ed il parser prova nuovamente.
+
+    var foo = function() {
+    }; // nessun errore, il parser continua
+    test()
+
+L'inserimento automatico dei punti-e-virgola è considerato essere uno dei
+**più grandi** errori di progettazione del linguaggio, perché *può*
+modificare il comportamento del codice.
+
+### Come funziona
+
+Il codice qui sotto non ha punti-e-virgola, quindi sta al parser decidere dove
+inserirli.
+
+    (function(window, undefined) {
+        function test(options) {
+            log('testing!')
+
+            (options.list || []).forEach(function(i) {
+
+            })
+
+            options.value.test(
+                'long string to pass here',
+                'and another long string to pass'
+            )
+
+            return
+            {
+                foo: function() {}
+            }
+        }
+        window.test = test
+
+    })(window)
+
+    (function(window) {
+        window.someLibrary = {}
+
+    })(window)
+
+Di seguito il risultato del gioco da "indovino" del parser.
+
+    (function(window, undefined) {
+        function test(options) {
+
+            // Non inserito, linee unite
+            log('testing!')(options.list || []).forEach(function(i) {
+
+            }); // <- inserito
+
+            options.value.test(
+                'long string to pass here',
+                'and another long string to pass'
+            ); // <- inserito
+
+            return; // <- inserito, invalida l'istruzione return
+            { // trattato come un blocco
+
+                // un'etichetta e una singola espressione
+                foo: function() {}
+            }; // <- inserito
+        }
+        window.test = test; // <- inserito
+
+    // Le linee vengono unite nuovamente
+    })(window)(function(window) {
+        window.someLibrary = {}; // <- inserito
+
+    })(window); //<- inserito
+
+> **Nota:** il parser del JavaScript non gestisce "correttamente" le istruzioni
+> return che sono seguite da un ritorno a capo. Mentre questo non è necessariamente
+> da considerarsi un errore dell'inserimento automatico di punti-e-virgola, esso
+> può ancora essere considerato un effetto collaterale indesiderato.
+
+Il parser ha drasticamente modificato il comportamento del codice. In alcuni casi,
+questo porta ad eseguire **cose sbagliate**.
+
+### Parentesi ad inizio riga
+
+Nel caso di parentesi ad inizio riga, il parser **non** inserirà un punto-e-virgola.
+
+    log('testing!')
+    (options.list || []).forEach(function(i) {})
+
+Questo codice viene trasformato in una sola linea.
+
+    log('testing!')(options.list || []).forEach(function(i) {})
+
+Le possibilità che `log` **non** ritorni una funzione sono **veramente** alte,
+perciò il codice qui sopra porterà ad un `TypeError` dichiarando che
+`undefined is not a function` (undefined non è una funzione).
+
+### In conclusione
+
+&Egrave; fortemente raccomandato di non omettere **mai** i punti-e-virgola.
+Si raccomanda anche di mantenere le parentesi sulla stessa linea della
+corrispondente istruzione, e di non ometterle mai in istruzioni `if` / `else`
+a linea singola. Queste misure precauzionali non solo miglioreranno la
+consistenza del codice, ma preverranno anche che il parser JavaScript
+modifichi il comportamento del codice in modo inaspettato.
+