JavaScript è morto. Lunga JavaScript diretta!

Da 16 anni, JavaScript è il linguaggio del browser web. Questo linguaggio ha permesso la costruzione di applicazioni web convincenti e contribuito al successo del web. Altri linguaggi di scripting potrebbero hanno riempito il ruolo JavaScript fa ma JavaScript era nel posto giusto al momento giusto. Microsoft ha aggiunto di base per Internet Explorer molto tempo fa, ma JavaScript era la lingua in tutti i browser e così ha vinto. Poiché JavaScript è cross-browser e almeno abbastanza buono, i produttori di browser non hanno avuto bisogno di aggiungere altri interpreti di lingua per i browser stessi.

Ma ancora non abbiamo scelto di usare JavaScript. È stato l'unica opzione. Ha caratteristiche potenti come le chiusure e abbiamo imparato ad amare queste caratteristiche mentre si gira un occhio alle parti verrucosa del linguaggio. C'è anche stato un sacco di chiedere scusa alla comunità dei programmatori sulla falsariga di "Sì sappiamo che è una lingua piuttosto funky, ma si prega di dargli una possibilità. Sono sicuro che imparerete ad amarlo. "Non dovrebbe essere difficile vendere la qualità del linguaggio. JavaScript è stato descritto come un esperimento sfuggito il laboratorio un po 'troppo presto e siamo stati bloccati con le verruche da allora.

Eppure, JavaScript è stato un grande linguaggio. Nel 2007, Steve Yegge dichiarato JavaScript come The Next Big lingua ed è stato. Tra allora e adesso basato su JavaScript web-applicazioni sono diventati più grandi e migliori. Con l'aiuto di JavaScript, il web ha continuato a svilupparsi anche con la minaccia di applicazioni mobili native presa in consegna lo stesso spazio.

In tempi molto recenti, JavaScript ha fatto il suo tentativo più riuscito ad essere un linguaggio server-side. La piattaforma Node.js, con la sua non-blocking I / O, possono essere risolvere un problema che i programmatori avere bisogno risolto per lungo tempo. JavaScript è il linguaggio per Node.js e così JavaScript può andare avanti per il giro di diventare un linguaggio server-side di successo dopo molti tentativi falliti in passato.

Nel complesso, JavaScript è stato un successo selvaggio. Il linguaggio di programmazione più popolare nel mondo. Ma se il browser è morto oggi, quanto il nuovo codice JavaScript sarebbe da scrivere domani? Molto probabilmente JavaScript sarebbe diventato un giorno all'altro lingua frangia. Ma il browser non sta morendo domani. Saremo programmazione per esso per gli anni a venire.

Come è stato utilizzato JavaScript per ulteriori e più grandi programmi, le verruche del linguaggio sono diventati più evidenti e ha causato crescenti quantità di dolore per molti sviluppatori. Può essere una sorpresa che, anche se ho scritto su JavaScript per anni, io non sono un fanboy JavaScript. La maggior parte dei miei articoli JavaScript sono stati per me lavorare attraverso le difficoltà di trovare una coesistenza pacifica con la lingua. Sì ho apprezzato la programmazione in JavaScript e ho imparato molto, ma c'è sicuramente sono stati momenti in cui mi sono sentito come se fossi sguazzare nel fango.

Una delle carenze più evidenti in JavaScript è con la sua interfaccia utente: la sua sintassi. L'incapacità di migliorare rapidamente la sua sintassi ha portato alla caduta del linguaggio.

Il caso per le estensioni di sintassi: Verbose Idioms

Qui guardiamo solo quattro dei tanti esempi in cui la sintassi di JavaScript potrebbe essere migliorata per rimuovere idiomi verbose dalle nostre esistenze quotidiane di programmazione.

Parametri e valori predefiniti Optional

Funzioni JavaScript può essere chiamato con un numero variabile di parametri attuali. Questo rende alcuni dei parametri formali nella dichiarazione della funzione opzionale. Spesso questi parametri opzionali devono essere impostati a un valore predefinito se nessun parametro reale è fornita. Sono pronto a scommettere che hai scritto e visto un sacco di codice come il seguente.

function (a, b, opzionale) {
    option = opzione || {};
    // ...
}
Ho e ancora scrivere il codice come questo. Questo codice è sbagliato. Se un valore falsy è passato alla funzione per l'opzione allora la cosa sbagliata accade. Dovremmo scrivendo quanto segue.

function (a, b, opzionale) {
    option = arguments.length> 2? Opzione: {};
    // ...
}
Anche se questo codice esprime il pensiero previsto di fissare un valore predefinito se un parametro attuale per l'opzione non viene fornito, è troppo prolisso e meno leggibile. Il lettore deve contare per determinare quale variabile si ha indice 2. Al di là del disagio, la versione corretta è più difficile da mantenere. È facile produrre il seguente codice buggy se il b parametro viene rimosso.

function (a, opzionale) {
    option = arguments.length> 2? Opzione: {};
    // ...
}
Se l'applicazione utilizza parametri facoltativi con valori di default, qualche nuova sintassi sarebbe vantaggioso per voi.

function (a, b, opzione = {}) {
    // ...
}
L'aggiunta di questa nuova sintassi sintonizza la lingua meglio alle esigenze della vostra applicazione.

Lasciare

Fa il seguente codice buggy sembra familiare?

for (var i = 0, ilen = elements.length; i <ilen; i ++) {
    elemento var = elementi [i];
    LIB_addEventListener (elemento, 'click', funzione (evento) {
        alert ('Sono stato originariamente numero' + i);
    });
}
Tutti gli elementi sono lo stesso numero ?! La soluzione è quella di utilizzare una espressione funzione immediatamente valutata in modo che ogni avviso segnala un numero diverso. Questo è l'idioma "let", dopo vari di Lisp Let forme.

for (var i = 0, ilen = elements.length; i <ilen; i ++) {
    elemento var = elementi [i];
    (Function (num) {
        LIB_addEventListener (elemento, 'click', funzione (evento) {
            alert ('Sono stato originariamente numero' + num);
        });
    } (I));
}
Certo a volte delegano ascoltatori potrebbe essere migliore di codice di cui sopra, ma a volte il codice di cui sopra è l'idea desiderata. Nel caso di cui sopra, stiamo cercando di legare l'ordine degli elementi quando il ciclo viene eseguito. Questo ordine può essere perduto con il modello delegato se gli elementi sono riorganizzate nel DOM.

Questa sintassi è particolarmente scomodo a causa della distanza tra il convenzionale num ed effettivi i parametri della funzione immediata.

La funzione immediata potrebbe essere scomposto fuori in un altro luogo e chiamato all'interno del ciclo.

Funzione attachListener (elemento, num) {
    LIB_addEventListener (elemento, 'click', funzione (evento) {
        alert ('Sono stato originariamente numero' + num);
    });
}
for (var i = 0, ilen = elements.length; i <ilen; i ++) {
    attachListener (elementi [i], i);
}
Anche con questa opzione, a volte i programmatori usano ancora la funzione immediata perché trasmette meglio il loro messaggio destinato ai lettori.

Se l'applicazione utilizza l'idioma let, non sarebbe bello avere nuova sintassi per esso?

for (var i = 0, ilen = elements.length; i <ilen; i ++) {
    elemento var = elementi [i];
    lasciare (num = i) {
        LIB_addEventListener (elemento, funzione (evento) {
            alert ('Sono stato originariamente numero' + num);
        });
    };
}
Con num e io insieme è molto più facile da leggere il codice e un nuovo ambito che contiene nuovo è stato introdotto così la chiusura funzioni correttamente. Ancora una volta, l'aggiunta di nuovo brano sintassi può il linguaggio meglio alle esigenze della vostra applicazione.

Moduli

Uno dei linguaggi più comuni programmi JavaScript che tutti noi conosciamo e amiamo è di solito chiamato "il modello di modulo." Questo linguaggio offre i vantaggi di variabili incapsulati che sono private al modulo e impartisce sanità mentale al nostro codice.

evento var = (function () {

    // variabili private
    ascoltatori var = [];
 
    funzione addEventListener (f) {
        listeners.push (f);
    }

    clearEventListeners function () {
        ascoltatori = [];
    }
   
    // ...
   
    // Esportare API del modulo
    ritorno {
        addEventListener: addEventListener,
        clearEventListeners: clearEventListeners
        // ...
    };
} ());
L'obiettivo di incapsulamento qui non è la sicurezza. E 'per garantire che altri sviluppatori mantenere i loro sporchi,-scimmia patching mani fuori dati del modulo.

L'esportazione può essere fatto un paio di modi, ma non importa in che modo vi è una certa piastra caldaia.

L'importazione è verbose anche

(Function () {

    // importazione desiderato proprietà del modulo di manifestazione
    var addEventListener = event.addEventListener;
    var clearEventListeners = event.clearEventListeners;
   
    // ...
} ());
Qualche nuova sintassi sarebbe bello per trasmettere l'intento del pattern modulo di meglio.

evento module {
   
    // variabili private
    ascoltatori var = [];
 
    funzione di esportazione addEventListener (f) {
        listeners.push (f);
    }

    clearEventListeners funzione di esportazione () {
        ascoltatori = [];
    }
   
    // ...
}
(Function () {

    evento import;
   
    // ...
} ());
Il modello modulo è quasi ovunque e qualche nuova sintassi per esprimere meglio questo idioma sarebbe meglio sintonizzare il linguaggio di tutte le nostre applicazioni.

Eredità

Questi esempi idioma sono cresciuti nel modo in cui ciascuna abbracciano un numero crescente di linee di codice. Il linguaggio JavaScript che si estende potenzialmente la maggior parte delle linee del vostro programma può essere il linguaggio eredità.

funzione Employee (primo, ultimo, posizione) {
    // Chiamare il costruttore della superclasse
    Person.call (questo, in primo luogo, l'ultima);
    this.position = posizione;
};
// Ereditare da persona
Employee.prototype = Object.create (Person.prototype);
Employee.prototype.constructor = Impiegato;

Metodo // definire un toString overridding ()
Employee.prototype.toString = function () {
    Metodo // toString ridefinito chiamare di superclasse ()
    ritorno Person.prototype.toString.call (questo) +
           'È un' + this.position;
};
Che casino. Si JavaScript rende l'ereditarietà singola come questo possibile prototipi collegano ma ci vuole un sacco di codice per fare manualmente le cose eccellenti che accadono così come si potrebbe eredità al lavoro.

Se ci potrebbe essere un incubo di manutenzione che è. Le stringhe "persona" e "dipendenti" sono distesi in tutto il codice per la "classe" Employee.

Se le classi con ereditarietà sono una grande parte della propria applicazione, una sintassi sarebbe davvero aiutare a ripulire il codice. Forse qualcosa di simile a quanto segue.

class Employee estende Person {
    constructor (primo, ultimo, posizione) {
        super (primo, ultimo);
        posizione pubblica = posizione;
    }

    update (fotocamera) {
        super.update ritorno () + 'è un' position +;
    }
}
Questo è un grande miglioramento.

Imparare dai Idiomi

Questi idiomi comuni rendono chiaro che JavaScript potrebbe usare qualche nuova sintassi per diverse ragioni. La capacità di fare ciò che vogliamo è solitamente in JavaScript da qualche parte. La verbosità degli idiomi è a volte troppo. Abbiamo tagliato angoli. A volte evitiamo certi algoritmi perché gli idiomi sono troppo prolisso. Gli idiomi non sono autoesplicativi. Sono segreti all'interno della comunità e l'intento non è facilmente riconoscibile da parte di estranei.

Il Comitato ECMAScript ha riconosciuto che gli idiomi di cui sopra, e altri idiomi, sono comuni in una vasta gamma di applicazioni. Ci sono proposte per tutti questi casi di sintassi in Harmony. Alcuni di loro possono farlo nella prossima versione di ECMAScript e nei browser per il vostro uso. Se nuova sintassi arriva alla fine, allora si può utilizzare usarlo.

Idiomi possono sono emerse nel vostro applicazione che non appaiono in una vasta gamma di applicazioni. Ad esempio, non-blocking I / O e la forte dipendenza di Node.js su callback indubbiamente comporterà idiomi che non appaiono negli script del browser. Sintassi specifica solo le applicazioni probabilmente mai farne ECMAScript.

Se si desidera utilizzare la sintassi specializzata per gli idiomi generali come quelle mostrate in precedenza o se volete la sintassi per i propri idiomi, cosa si può fare?

Se solo avessimo Macro

Lingue Lisp hanno avuto le macro in piena regola per decenni. Attraverso le macro, Lisp offre ai programmatori la possibilità di regolare la sintassi del linguaggio per soddisfare meglio le proprie applicazioni. A causa delle sue macro, Lisp è stato descritto come "il linguaggio di programmazione programmabile." Roba potente.

Di s-espressione sintassi Lisp, si sa, la sintassi con tutte quelle parentesi, dà il linguaggio una proprietà speciale chiamato homoiconicity. Significa circa la sintassi del linguaggio è anche la sintassi delle sue strutture di dati o che albero sintattico di un programma utilizza le strutture di formati di dati. Questo homoiconicity rende macro di Lisp possibile.

JavaScript non ha le macro. Una delle principali ragioni di ciò è che l'aggiunta di macro per linguaggi con C-come sintassi, le lingue che non sono homoiconic, è ancora un argomento di ricerca. Estratti da una breve conversazione su Twitter con littlecalculist, Dave Herman, Ph.D., ECMAScript membro del comitato, e Mozilla Ricercatore:

petermichaux
Credolittlecalculist sa di più sulla ricerca e le possibilità per le macro di ECMAScript. Mi piacerebbe sapere di più anche.
littlecalculist
Ho pensieri su di sicuro. Ma macro per le lingue non sexp è ancora molto un argomento di ricerca impegnativo
petermichaux
[...] Ci rivolgiamo blu in attesa per le macro.
littlecalculist
Potrei suggerire di mantenere la respirazione? ;-) Scherzi a parte, spero di provare, ma credetemi, la progettazione del sistema macro è difficile.
Il messaggio è abbastanza chiaro. Macro JavaScript non sono proprio dietro l'angolo.

Harmony Sintassi ETA

Forse le estensioni di sintassi in Harmony sono tutti sogni e altro ancora. Se Harmony diventa ECMAScript 6 e ECMAScript 6 diventa onnipresente allora sarete tutti insieme. Quindi tutto quello che dovete fare è aspettare ... pazienza.

In primo luogo, diamo un'occhiata a adozione del browser. Purtroppo io prendersela con Internet Explorer un po ', che è diventato quasi un cliché, ma non perché ho qualcosa contro il team di sviluppo di Internet Explorer di Microsoft o le versioni più recenti di Internet Explorer. E 'necessario guardare a questa del browser perché è forse il più importante studio caso per stimare quando funzioni saranno disponibili per tutti i visitatori del tuo sito web.

A partire da maggio 2011, w3schools , che ha visitatori relativamente tech-savvy, rapporti di Internet Explorer 6 ha ancora il 2,4% di quota di mercato. Net Market Share riporta Internet Explorer 6 ha ancora una quota di mercato pari al 10,36%. Il tuo sito probabilmente ha una quota di mercato da qualche parte tra questi due numeri, ma questo browser è ancora appeso anche se è stato sostituito da Internet Explorer 7 in novembre 2006. Quante persone stanno ancora utilizzando Internet Explorer 6 o 7? Il sito mostra W3Schools 7,7% e Net Market Share mostra 18,2%. Questi browser semplicemente non stanno andando via abbastanza velocemente. Un sito accessibile al pubblico (ad esempio Amazon) non può permettersi di ignorare i numeri di quote di mercato questo di grandi dimensioni.

Non vi è alcun senso spendere qualsiasi lamenti energia che gli utenti dovrebbero aggiornare i loro browser, o che "IE devono morire!" Non succederà. Non so se è vero, ma qualcuno una volta mi disse: "Gli utenti di Internet Explorer aggiornare il browser quando aggiornano il loro hardware." Negli ultimi anni, l'hardware è sicuramente diventato sufficiente che le persone non hanno bisogno di aggiornare nulla a utilizzare la posta elettronica, Facebook, Twitter, etc.

Supponiamo che il vostro web app è così avanzata che avete deciso che vi interessa soltanto gli utenti dotati di browser "moderni". Google Apps ha recentemente annunciato che il 1 Agosto 2011 si fermeranno a sostegno di Internet Explorer 7. Questo è quasi 5 anni dopo Internet Explorer 7 è stato rilasciato.

Ora pensate a questo: Internet Explorer 10 non è ancora uscito, ma, naturalmente, anche se non avrà le estensioni di sintassi di Harmony. Facciamo stimano che Harmony è approvato come ECMAScript 6 a metà del 2012 e Internet Explorer 11 è rilasciato nei primi mesi del 2013, con il supporto per tutte le sintassi di Harmony. Cinque anni dopo, nel 2018, il team di Google Apps può cadere il supporto per Internet Explorer 11 e, infine, utilizzare la sintassi Harmony liberamente. (Il 1 ° agosto 2011, sono anche abbandonare il supporto per quattro anni, Safari 3 e due anni, Firefox 3.5 in modo che le attese sono ancora a lungo ish per altri browser anche.)

Gli sviluppatori di Amazon potrebbe essere necessario attendere altri 5 anni prima di poter usare la sintassi Harmony. Questo è 2023!

Sarete soddisfatti attesa 7-12 anni prima di poter iniziare a utilizzare la sintassi che sarebbe utile sviluppare le vostre applicazioni web oggi? Essere più ottimisti, anche se l'attesa è a soli 5 anni, vuoi aspettare?

JavaScript è morto.

Causa della morte: cancro virgola.

Forse a causa della sintassi di JavaScript sola, JavaScript non ha le macro ora e non li hanno presto se mai. Milioni di programmatori usano JavaScript ora e molti di loro sono stanchi o faticoso degli idiomi verbose confrontano quotidianamente. Vogliono nuova sintassi ora e non aspettare. Per questo gruppo crescente di sviluppatori, il linguaggio Javascript codice sorgente è morto.

Hai avuto un buon regno, JavaScript. Abbiamo avuto alcuni buoni tempi e scritto alcune applicazioni cool insieme. Che tu possa riposare in pace.

Lunga JavaScript diretta!

I programmatori piace di controllare il proprio destino e che stanno prendendo provvedimenti. Si possono avere tutte la nuova sintassi che si desidera per gli script del browser, in questo momento, se si scrive in un'altra lingua di origine e compila il ECMAScript 3 dialetto JavaScript per i miliardi di browser in natura. Compilando per ECMAScript 3 si sono completamente liberati dalla evoluzione sintattica di JavaScript. Come bonus aggiuntivo, si può anche risolvere alcuni dei trucchi semantici di JavaScript con un compilatore sufficientemente sofisticato. Nuova vita di JavaScript è un obiettivo compilation.

Lingue compilare in JavaScript

Ci sono stati i compilatori di JavaScript per anni. Nel 2007, ho cominciato a raccogliere un elenco di lingue con i compilatori a JavaScript. C'erano lingue estensione JavaScript: la ormai defunta ECMAScript 4, Narrative JavaScript, e Objective-J. C'erano preesistenti lingue: regime, Common Lisp, Smalltalk, Ruby, Python, Java, C #, Haskell, ecc Ci sono stati anche nuovi linguaggi di zecca haXe, Milescript, Links, Flapjax che sono stati progettati per soddisfare le esigenze di programmazione web.

Di questi progetti compilatore, il compilatore GWT di Google Java-to-JavaScript è stato probabilmente il più riuscito, ma non vedo i programmatori che per primo ha imparato una lingua diversa Java correre da usare Java come linguaggio di codice sorgente. In realtà, nessuno di questi progetti compilatore hanno maturato una significativa base di utenti a lungo termine. Almeno nelle parti del web che frequenti, con l'eccezione di GWT, è raro leggere di programmatori che utilizzano questi compilatori per i progetti reali. Ci sono diversi motivi legittimi per non utilizzare uno di questi compilatori.

Immaginate di costruire un grande progetto utilizzando uno di questi compilatori e parte attraverso trovare un bug nel compilatore. Quello manutentore del compilatore può avere interesse o tempo perduto. Vuoi mantenere un compilatore? Qualcuno della tua squadra ha le competenze per farlo? Che ulcera sta per arrivare abbastanza grande mentre vi preparate a spiegare al CEO che è ora necessario riscrivere l'interfaccia utente in JavaScript.

Solo il pensiero di debug del codice compilato quando un bug di produzione è archiviato mi fa rivoltare lo stomaco. Core dump. Quale linea numero nel codice sorgente corrisponde al numero di riga Firebug riporta per il codice compilato? AFFRETTATI! Questo bug deve essere risolto ora !!!!

Hai usato Objective-J per un grande progetto e ora è necessario assumere un nuovo buon programmatore. Quali sono le possibilità di trovare la persona giusta? Probabilmente sono molto bassi. Basta trovare un programmatore JavaScript disponibile è abbastanza difficile. Se si utilizza una di queste lingue alternative, è molto probabile che avrete bisogno di addestrare ogni nuova persona che si aggiunge al tuo team.

Anche senza questi progetti compilatore essere di grande successo, la lista delle lingue che compila a JavaScript ha continuato a crescere. Non vi è dubbio che scrivere un compilatore a JavaScript è un progetto molto cool. Vi prego di pagare di scrivere uno.

C'è una new entry notevole nella lista delle lingue che compilano a JavaScript che è in realtà causando un grande scalpore e sta forse cambiando il gioco per buona.

CoffeeScript

Vi posso dire in questo momento, non so perché CoffeeScript ha la magica combinazione di caratteristiche per raccogliere l'attenzione che ha quando altri progetti hanno fallito. Spazi significativi e sintassi della funzione freccia. La mia reazione istintiva è che schifo. C'è un sacco di cose per piacere: i valori dei parametri di default, i parametri di riposo, la diffusione, destrutturazione, che fissa tutto il casino globale implicito, anche le classi se siete in questo genere di cose e di più. Molte delle caratteristiche del CoffeeScript sono parte di Harmony e così potrebbe essere nei browser in futuro, ma se si utilizza CoffeeScript allora si può avere adesso. Non c'è nulla come una gratificazione immediata.

I programmatori sono pieni di affetto per CoffeeScript.

pyronicide
Essere in grado di utilizzare i valori di default per gli argomenti delle funzioni in #coffeescript mi ​​rende immensamente felice.
_jdpage
CoffeeScript è meraviglioso. Ora sono viziati e lamenterò ogni volta che devo scrivere JavaScript invece.
Alla conferenza TXJS 2011, Douglas Crockford apparentemente condiviso che pensa "CoffeeScript è chiaramente roba buona."

C'è un aspetto del progetto CoffeeScript che mi piace molto ed è riassunta dalle seguenti due citazioni. Il primo viene da Trevor Burnham, autore di CoffeeScript: Accelerated Development JavaScript .

trevorburnham
[...] Non si tratta di trasformare in JS Rubino / Python; si tratta di avere una sintassi più adatto alla bontà interiore di JavaScript.
Il secondo è da The Little Book on CoffeeScript .

CoffeeScript evita accuratamente queste [questioni JavaScript], solo esponendo una selezione curata di funzioni JavaScript.

L'atteggiamento espresso in queste citazioni è davvero grande e genio del marketing troppo. Non è CoffeeScript versi JavaScript. È CoffeeScript migliorare l'esperienza di programmazione JavaScript. Potrebbe un po 'diverso di sintassi e un sottoinsieme limitato di funzioni di JavaScript davvero essere migliore di Plain Old JavaScript?

Douglas Crockford sembra pensare così. Per anni, il suo JSLint è stato male i nostri sentimenti ed esigente che usiamo gli spazi e la sintassi molto specifico e che evitiamo funzioni JavaScript pericolosi. Il codice sorgente che passa JSLint ha accesso a un vero e proprio sottoinsieme di JavaScript: ". Le parti buone" il sottoinsieme che chiama Questo dialetto di JavaScript merita un nome. Forse GoodScript? Dopo tutto, è consentito utilizzare solo JSLint per il bene e non per il male.

Il Comitato ECMAScript pensa anche questa è una buona idea. Il "use strict" pragma introdotto in ECMAScript 5 non limita solo alcune caratteristiche del linguaggio, come con , anche in modalità rigorosa modifiche / fissa la semantica di alcune parti del linguaggio. A causa dei cambiamenti semantici, ECMAScript 5 rigorosa è una lingua diversa o almeno un dialetto diverso ECMAScript 5 non rigida.

CoffeeScript, GoodScript, e ECMAScript 5 rigoroso condividere obiettivi comuni di tenere lontano dalle parti pericolose JavaScript dando accesso alle parti, sicuro valore. Ognuno fa rispettare questi obiettivi in ​​modo diverso, ma la loro applicazione in un modo o nell'altro. Non si ottiene nuova sintassi con GoodScript. È già JavaScript e pronto per il browser. Non si arriva a usare ECMAScript 5 rigorosa perché non è disponibile in tutti i browser ancora e non sarà per anni.

Così CoffeeScript sembra mira un bisogno particolare di sviluppo web e forse è qualcosa di diverso da JavaScript compilatori non hanno fatto o non hanno fatto molto prima.

CoffeeScript è anche una pelle abbastanza sottile su JavaScript. Una conseguenza di questo è che il codice JavaScript compilato è ragionevolmente facile da leggere e non brutale di debug (così mi hanno detto.) Questa debug paura ridotta contribuisce agli interessi in CoffeeScript.

CoffeeScript sente quasi come un insieme di macro per la scrittura di programmi JavaScript.

Dal momento che i compilatori CoffeeScript sono nelle mani degli sviluppatori, piuttosto che i visitatori ai siti, di controllare la versione di CoffeeScript in uso. È possibile aggiornare a volontà. Questo significa anche CoffeeScript non ha bisogno di essere standardizzati e passare attraverso la successiva dolorosamente lenta crescita di un linguaggio standardizzato. CoffeeScript può crescere al ritmo dell'immaginazione di sua comunità e il desiderio. JavaScript standardizzazione è stato essenziale per il successo del web, ma gli stessi vincoli non si applicano a CoffeeScript.

Bene, allora ho

Il modo più semplice per navigare i metodi di una classe utilizzando scorciatoie da tastiera Eclipse

Classi Java possono ottenere grandi e peloso, il che rende difficile trovare il metodo che cerchi durante la navigazione o la modifica di una classe. Non vi è alcun ordine specifico per cui i metodi possono essere in una classe e diversi sviluppatori hanno diverse preferenze su dove metterli.

È possibile utilizzare la rotellina del mouse e scorrere ferocemente fino alla fine a trovare il metodo o si potrebbe anche utilizzare Page Down / Pagina Su sulla tastiera. Ma questi metodi possono essere in termini di tempo e casuale, soprattutto quando la classe ha un sacco di metodi o stanno sparsi in un ordine arbitrario.

Fortunatamente, Eclipse ha un certo numero di modi facili e veloci per aiutarvi a navigare i metodi in una classe, in particolare utilizzando la tastiera. Parlerò alcune di queste scorciatoie da tastiera e anche quelli che da utilizzare quando.

L'Outline rapida è sostanzialmente una versione popup ridotta della Outline View. Il principale vantaggio rispetto Outline View è che ha una casella di ricerca che permette di cercare un metodo.

Ecco come utilizzare il Outline rapida:

Premere Ctrl + O da qualsiasi punto all'interno della classe.

Digita un termine di ricerca nella casella di ricerca e Eclipse sarà solo mostrerà tutti i metodi che corrispondono al termine di ricerca. Per impostazione predefinita Eclipse fa una ricerca esatta corrispondenza, ma è possibile utilizzare i caratteri jolly.

Una volta che si vede il metodo che ti interessa, premere Giù per selezionare il metodo (se non è già selezionata).

Premere Invio una volta selezionato il metodo. Eclipse vi porterà direttamente alla dichiarazione del metodo.

Questo è un esempio di popup per Java ArrayList .

Ricerca di * rem cercherà tutti i nomi dei metodi che contengono la parola rem . Ecco un esempio:

Note:

Ordina la visualizzazione tramite il menu la freccia verso il basso nell'angolo in alto a destra. Rende più facile trovare i metodi di scansione.

Ridimensionare la Outline popup veloce per vedere più metodi. Eclipse ricorda le dimensioni del popup per la prossima volta che si apre.

Successivo membro e precedente membro

Un altro modo per muoversi tra i metodi è quello di utilizzare due funzioni chiamate Go To Next Stati e vai a precedente membro.

Quando si preme Ctrl + Maiusc + Giù , Eclipse si sposta il cursore al metodo successivo nella classe. Premendo Ctrl + Maiusc + si sposta al metodo precedente.

Ecco un video per darvi un rapido esempio di come queste scorciatoie funzionano:

Questa scorciatoia funziona meglio se sei già posizionato in un metodo o se la classe ha pochi campi. Questo perché Eclipse dell'utente può essere un metodo o un campo. Se sei al top della classe, si deve spostare attraverso tutti i campi prima di iniziare effettivamente muoversi attraverso i metodi stessi, un processo che richiede tempo soprattutto per le classi più grandi con un sacco di campi.

Aiuta a generare getter e setter nella parte inferiore della classe , perché non si dispone di navigare attraverso di loro per arrivare ai metodi utili.

Aprire Dichiarazione

Se hai un sacco di metodi privati ​​della tua classe, allora Apri dichiarazione potrebbe essere il modo migliore per spostarsi tra di loro.

Quando sei posizionato su una chiamata di metodo e premere F3 , Eclipse vi porta direttamente alla definizione di tale metodo. Ad esempio, se sei impegnato nel metodo process () e posizionato sul del cursore initProcessing () , premendo F3 vi porterà direttamente alla dichiarazione di quel metodo più in basso della classe.

pubblico  nullo  processo () {

   // Fare le cose ...

   initProcessing ();

privato  vuoto  initProcessing () {

   // Init qualcosa ...

Questa caratteristica funziona molto bene con Alt + Sinistra (History indietro). Vedere la sezione di seguito per maggiori dettagli circa la storia indietro.

Navigazione Torna a un metodo in precedenza Visto

Durante la navigazione del codice, spesso si vuole tornare al metodo precedente si stava visualizzando una volta che hai finito visualizzando il metodo che chiama.

Per fare questo, utilizzare Alt + Sinistra (History indietro) per tornare all'ultimo punto di navigazione. Questa caratteristica non è specifico per soli metodi, ma anche opere per la navigazione tra i redattori precedentemente visitati. Ma funziona grande se hai appena stato navigando metodi all'interno di una classe.

Di Eclipse Outline View permette anche una facile navigazione, ma soprattutto con il mouse. Si potrebbe passare alla visualizzazione con Alt + Shift + Q, O , e si può passare a metodi digitando la prima lettera, ma ho trovato il contorno veloce per essere più tastiera amichevole. Inoltre, la visualizzazione Struttura non supporta le ricerche jolly.

È inoltre possibile utilizzare Eclipse Gerarchia di richiamo ( Ctrl + Alt + H ), soprattutto se si sta cercando di capire il flusso di metodi in una classe e spostarsi tra di loro facilmente. Saper navigare tra le visualizzazioni ed editor con la tastiera aiuta molto in quanto sarete in movimento tra la vista Gerarchia di richiamo e gli editori molto.

Cosa devo usare Quando?

Utilizzare successivo / precedente Stati scorciatoia se la classe è piccola o avete una buona idea di dove altri metodi sono in relazione al metodo attuale (ad es. Sono loro sopra / sotto il metodo corrente).

Utilizzare il contorno veloce se non si conosce la classe troppo bene o ci sono un sacco di metodi nella classe.

Utilizzare aperta dichiarazione, se si sta spostando tra molti metodi privati ​​della classe. E 'di solito il modo più veloce per passare a un altro metodo privato della classe, ma solo se si sta già posizionato in un metodo che chiama.

Convertire nidificati / classi anonime in classi di livello superiore che utilizzano Eclipse refactoring

Classi nidificate , ad esempio. classi anonime, sono spesso più conveniente rispetto alla creazione di classi separate, soprattutto quando si lavora con qualcosa come il modello di comando o listener di eventi. Per esempio:

Tasto JButton = nuovo  JButton ();
button.addActionListener ( nuovo  ActionListener () {
    Override
    pubblico  vuoto  actionPerformed (ActionEvent e) {
        // ... Fare qualcosa di utile
    }
});
Ma arriva un momento in cui la classe nidificata diventa così ingombrante che il codice diventa illeggibile. E a volte si vuole riutilizzare la stessa classe in un altro posto - qualcosa che è difficile con le classi interne anonime.

La risposta potrebbe essere quella di cambiare la classe annidata in una classe pubblica di livello superiore (o un cittadino di prima classe, se volete) che esiste nel proprio file (ad es. SomethingUsefulActionListener.java ). Ma fare questo manualmente può richiedere molto tempo ed è soggetto a errori.

Eclipse ha un paio di refactoring e soluzioni rapide che contribuiscono a rendere il lavoro molto più facile. Conversione di una classe interna anonima a una classe di livello superiore richiede solo due refactoring e vi porterà un paio di secondi invece di minuti. A (nome) classe interna richiede solo un refactoring. E il passaggio di argomenti per la nuova classe è anche facile se si utilizzano alcune delle correzioni rapide di Eclipse.


Pubblicità



Convertire la classe interna anonima in un livello superiore

Conversione di una classe interna anonima in una classe di livello superiore richiede 2 refactoring principali: Conversione in una classe annidata e poi convertire la classe annidata a una classe di livello superiore. Se si dispone di una classe annidata (es. Una classe interna denominata), poi basta iniziare al punto 4.

Qui ci sono le istruzioni, ma c'è anche un video qui sotto con un esempio veloce.

1. Convertire la classe interna anonima a una classe annidata in piedi sulla classe costruttore anonimo 'e scegliendo Refactor> Converti Anonymous Class a nidificati ... (o Alt-T, O ). Apparirà una finestra di dialogo che richiede per i dettagli di classe nidificati.



2. Inserire un nome per la nuova classe nidificato, selezionate pubblico come la visibilità e deselezionare dichiarare il tipo nidificato come definitiva .



3. Fare clic su Ok. Eclipse creerà una nuova classe annidata all'interno della classe contenitrice e lasciare la chiamata al costruttore in cui la classe anonima utilizzata per dichiarare.

4. Ora convertire la classe annidata in una classe di livello superiore in piedi sul nome della classe e scegliendo Refactor> Converti tipo membro Top Level ... (o Alt-T, V ). Apparirà una finestra di dialogo che richiede per il nome dell'istanza racchiude.



5. (Facoltativo) Se si desidera accedere alla classe contenitrice entro la nuova classe, quindi immettere un nome per il campo che verrà assegnato alla classe. Io di solito lasciare vuoto.

6. Fare clic su Ok. Eclipse sarà creare la nuova classe ( UsefulAction.java ) e spostarlo in un nuovo file nello stesso pacchetto.

Ecco un breve video per mostrare come questo è facile. Nell'esempio, convertiremo un anonimo interno ActionListener classe per una classe denominata UsefulAction.java .



Pubblicità


Passando argomenti dalla classe racchiude nella nuova classe

Che dire quando la classe annidata accede campi nella classe di inclusione? Come ottenere facilmente campi privati ​​della classe contenitrice nella nuova classe di livello superiore?

Non c'è un modo one-shot per fare questo, ma ci sono le tecniche per farlo andare un po 'più veloce. Un trucco è tramite le seguenti fasi:

Prima di tutto assicuratevi di aver creato una classe annidata chiamata (passi 1-3).
Copia e incolla i campi privati ​​rilevanti della classe contenitrice nella classe annidata.
Generazione automatica di un costruttore per la classe annidata in base ai campi appena copiato ( Alt + Maiusc + S, O ).
Passare l'errore di costruzione ( Ctrl +. ), dove viene creata un'istanza della classe annidata e aggiungere i campi al costruttore.
Il modo più semplice per vedere come funziona è quello di guardare il seguente video. Nell'esempio, passerò il campo nome e l'indirizzo per la nuova classe.