Perché ES6 non ha funzioni a freccia sottile?


16

ES6 ha aggiunto le funzioni fat-arrow ( =>), che hanno due differenze principali rispetto alle normali funzioni:

  • sintassi più breve (incluso il ritorno implicito se si utilizza un corpo a espressione singola)
  • ereditare thisdall'ambito circostante

Queste sono entrambe funzioni molto utili, ma mi sembrano completamente separate nel loro valore e nella loro applicazione - a volte ne voglio una, o l'altra, o entrambe, o nessuna delle due. Sembra strano che se voglio utilizzare una funzione a breve sintassi, ho devo utilizzare anche il thiscomportamento -modificare. E viceversa. Non vedo perché queste due funzionalità siano implementate come una singola aggiunta alla lingua.

E se volessi usare una breve funzione di sintassi per il suo ritorno implicito e la sua brevità (in alcuni contesti in cui un intero function (..) { return ...}sarebbe leggermente meno leggibile), ma vorrei usare thisnella mia funzione per fare riferimento al contesto chiamante? Non c'è modo di farlo.

CoffeeScript ha entrambe le funzioni ->e lo =>stile, e apparentemente ES6 ha preso in prestito lo =>stile da lì. Quindi la mia domanda è: perché ES6 non ha preso in prestito lo ->stile?


Le funzioni fat-arrow hanno altre differenze, come se non potessero legarsi arguments .
DeadMG

Se a volte tutto ciò che desideri è l'ambito circostante, puoi sempre associare this alla chiusura in una dichiarazione di funzione completa. Questa potrebbe non essere la parte di cui ti preoccupi.
Ben

Risposte:


25

Vedi la proposta di aggiungere funzioni freccia: http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax 1

Quello che dice è:

Tuttavia, non vogliamo CoffeeScript's ->, è confuso avere due frecce e dinamica questa rilegatura è una pistola sparata spesso.

Puoi anche vedere alcune discussioni su una versione precedente della proposta che aveva anche la sintassi ->: https://esdiscuss.org/topic/arrow-function-syntax-simplified

Sembra scendere al seguente:

  1. Avere due sintassi di freccia con semantica leggermente diversa aumenterebbe la complicazione e la confusione.
  2. Il dinamico questo legame di funzione () ed è ->stato ritenuto raramente utile, e un piede-pistola.
  3. Se hai davvero bisogno di questa associazione dinamica, puoi comunque usare function (), avere una sintassi di scorciatoia non è stato molto utile.

1
+1. Si noti in particolare che ES6 è il secondo tentativo di introdurre queste funzionalità, che erano originariamente previste per l'inclusione in ES4, ma le specifiche sono state abbandonate quando è diventato chiaro che le principali parti interessate ritenevano che fosse troppo complesso e che probabilmente rompesse la retrocompatibilità. Mantenere tutto il più semplice possibile deve essere stato un obiettivo importante per il comitato questa volta.
Jules,

1
Grazie per la tua risposta, ma non credo che la riguardi. Meno non significa più semplice; Direi che è più complesso dover passare tra due sintassi di funzioni molto diverse solo per ottenere una logica di associazione diversa (rispetto alla commutazione di un singolo carattere). Avere "più tipi di funzioni con semantica variabile" non è un'idea terribile; è esattamente quello che abbiamo in realtà. E non vedo cosa abbia a che fare con la retrocompatibilità con qualsiasi cosa di cui stiamo parlando. Non sto suggerendo che avrebbero dovuto rimuovere il supporto per la sintassi della funzione classica, se è questo che vuoi dire
callum

2
@callum, il consenso (almeno tra le persone che prendono questa decisione) è che lo function()stile di questo legame è stato un errore ed è una verruca sulla lingua. Se potessero, cambierebbero function()per avere =>semantica, ma non possono perché ciò romperebbe la compatibilità all'indietro.
Winston Ewert,

2
@WinstonEwert resisti, stai dicendo che le persone che prendono la decisione avrebbero preferito se potessero cambiare function()per ereditare thisdall'ambito circostante come =>fa? In tal caso, non si thisriferirebbe semplicemente all'oggetto globale ovunque? Suona strano. Dove l'hai sentito?
callum,

3
Questo può avere una risposta accettata, ma sembra un design del linguaggio scadente. Se hai una lingua che richiede una freccia grossa, allora dovrebbe essere disponibile anche una freccia sottile. Il primo costringe tutti a iniziare a pensare in termini di oggetti, mentre il secondo riconosce prima la storia javagram del design funzionale e il contesto differito.
Core
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.