Pot folosi sintaxa funcției săgeată din ES6 cu generatoare? (notarea săgeții) (Programare, Javascript, Ecmascript 6, Generator, Funcții Săgeată)

Ashley Coolman a intrebat.
a intrebat.

adică cum pot exprima acest lucru:

function *(next) {}

cu sintaxa săgeții. Am încercat toate combinațiile la care m-am putut gândi și nu pot găsi nicio documentație în acest sens.

(în prezent folosesc node v0.11.14)

Comentarii

  • Nu se poate. Îmi pare rău. „The function* statement (cuvântul cheie function urmat de un asterisc) definește o funcție generatoare.” – user663031
  • Rețineți că a existat o discuție oarecum lungă pe această temă la esdiscuss.org. –  > Por voithos.
  • La ce vă așteptați param*=>{ } să faci? –  > Por CoderPi.
  • știi că function(){} nu face același lucru ca și ()=>{} ? –  > Por CoderPi.
  • este într-adevăr că generatoarele ES6 sunt 2 pași înainte și 1 pas înapoi?” – nu, generatoarele pot face doar un pas înainte 🙂 –  > Por Bergi.
7 răspunsuri
user663031

Pot folosi sintaxa funcției săgeată din ES6 cu generatoare?

Nu puteți. Îmi pare rău.

În conformitate cu MDN

function* declarația (function urmată de un asterisc) definește o funcție generatoare.

De la o document de specificații (sublinierea mea):

funcția este extinsă pentru a adăuga un element opțional * opțional:

FunctionDeclaration: "function" "*"? Identifier "(" FormalParameterList? ")" 
  "{" FunctionBody "}"

Comentarii

    205

  • Mie mi se pare că este un defect de proiectare. –  > Por Jonathon.
  • 24

  • @Jonathon: Nu. Funcțiile de săgeată ar trebui să fie ușoare (și nu au o .prototype de exemplu) și adesea cu o singură linie, în timp ce generatoarele sunt cam opusul. –  > Por Bergi.
  • 43

  • Am întâlnit deja câteva scenarii în care un generator cu care mă jucam avea nevoie de acces la precedentul this, , și a trebuit să scrie let self = this hack pentru a obține acces la acesta în interiorul generatorului. Sintaxa lexical scope + arrow ar fi fost bună. Nefericit, dar nu este chiar sfârșitul lumii. –  > Por dvlsg.
  • 30

  • @Bergi raționamentul din spatele funcțiilor săgeată este mult mai complicat decât atât. Nu este vorba chiar de concizie. Funcțiile săgeată nu trebuie să fie ușoare – este adevărat că există o sintaxă opțională a corpului cu o singură declarație, dar și ce dacă. Mulți oameni folosesc săgeți pentru toate definițiile funcțiilor, cu excepția metodelor de clasă, și retrogradează function cuvântul cheie ca fiind o „parte rea” a limbajului. Există motive întemeiate pentru a face acest lucru. Pentru acești oameni, lipsa generatorilor de săgeți este o inconsecvență enervantă. –  > Por callum.
  • @callum Am vrut să spun „ușor” în ceea ce privește crearea de instanțe și apelurile, nu în ceea ce privește sintaxa. Nu sunt sigur care crezi că a fost raționamentul din spatele lor. Și nu, nu văd niciun motiv întemeiat pentru a folosi expresii de funcții săgeată nedeclarative în loc de function declarații. –  > Por Bergi.
CoderPi

Diferența dintre funcțiile Inline și funcțiile de tip Săgeată

În primul rând Funcțiile de tip săgeată () => {} nu sunt făcute pentru a înlocui funcțiile Inline. function(){} și sunt diferite.Funcțiile Inline sunt pur și simplu funcții, deci întrebarea este care este diferența dintre funcțiile Arrow și funcțiile Inline.

O expresie de funcție săgeată (cunoscută și sub numele de funcție săgeată) are o sintaxă mai scurtă în comparație cu expresiile de funcție și nu își leagă propriile this, , arguments, , super, , sau new.target). Funcțiile săgeată sunt întotdeauna anonime.

Câteva detalii rapide aici


De ce nu pot fi utilizate funcțiile săgeată ca generatoare

https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions

Utilizarea cuvântului cheie yield

yield nu poate fi utilizat în corpul unei funcții săgeată (cu excepția cazului în care este permis în cadrul funcțiilor imbricate ulterior în cadrul acesteia). În consecință, funcțiile săgeată nu pot fi utilizate ca generatoare.

Rețineți că generatori fără yield nu au sens.


De ce funcția săgeată nu poate utiliza randamentul

http://tc39wiki.calculist.org/es6/arrow-functions/

Funcțiile săgeată se leagă this din punct de vedere lexical, bind return în Bloc astfel încât să se întoarcă de la funcția săgeată care o înconjoară imediat și să împiedice break și continue să facă trimitere la instrucțiuni din afara funcției săgeată imediat următoare.

Adresa Identificator expresie primară arguments nu poate fi utilizat în corpul unei funcții săgeată (fie că este vorba de o expresie sau de un bloc).

De asemenea, yield nu poate fi utilizat în corpul unei funcții săgeată. Săgețile nu pot fi generatoare și nu dorim continuări profunde.

Dacă o funcție săgeată conține o expresie Yield, se va produce o eroare semantică: http://www.ecma-international.org/

În cele din urmă, motivul constă în complexitatea profundă a implementării ECMA6. C# nu permite acest lucru, de asemenea, din motive oarecum similare.

Comentarii

  • Am folosit un motor de căutare și am postat încă o explicație pentru dvs.  > Por CoderPi.
  • 70

  • Încerc să-mi dau seama de ce *() => { yield bla; } nu este în regulă, dar async () => { await bla; } este… –  > Por Lee Benson.
  • @CodeiSir, Re „și nu dorim continuări profunde„, niște scuze jalnice. –  > Por Pacerier.
  • 19

  • Argumentul dumneavoastră este ciclic. Spui că funcțiile săgeată nu pot fi generatoare pentru că nu pot avea în ele cuvântul cheie yield. Dar ele nu pot avea cuvântul cheie yield, pentru că nu pot fi generatoare: „Săgețile nu pot fi generatoare și nu dorim continuări profunde.” –  > Por Thayne.
  • Acesta este un raționament circular; o funcție săgeată nu poate fi un generator, deoarece nu este permis să aibă un yield și nu poate avea o instrucțiune yield declarație, deoarece nu are voie să fie un generator. –  > Por Sapphire_Brick.
monk-time

În plus față de discuția de pe esdiscuss.org și pe notele de la reuniunea ES6 a comitetului Ecma TC39 din noiembrie 2013 menționate mai sus, săgețile generatoare au fost revizuite în două reuniuni ES7 din septembrie 2016 [1] [2]. După o discuție despre avantajele și dezavantajele diferitelor sintaxe (în principal =*> și =>*) și a lipsei de justificări și de cazuri de utilizare pentru această caracteristică, au ajuns la concluzia că:

  • Există un oarecare interes din partea comitetului, dar există îngrijorarea că această caracteristică nu își face efectul pentru adăugarea unei noi părți de sintaxă.
  • Se intenționează să se revadă în ziua 3 pentru a vedea dacă putem obține =>* cel puțin la etapa 0, ca parte a propunerii de iterație asincronă a lui [Domenic Denicola].

Propunerea pentru săgețile generatoare a fost mutată la Etapa 1 cu Brendan Eich și Domenic Denicola ca campioni. Iterația asincronă menționată mai sus a fost finalizată și implementată în 2018.

În octombrie 2019 un repo oficial realizat de Sergey Rubanov a apărut cu mai multe discuții despre sintaxă și alte detalii.

Bhojendra Rauniyar

Și eu aveam aceeași întrebare și am venit aici. După ce am citit postările și comentariile, am simțit că utilizarea generatorului într-o funcție săgeată pare a fi vagă:

const generator = () => 2*3; // * implies multiplication
// so, this would be a confusing
const generator = () =>* something; // err, multiplying?
const generator = () =*> ... // err, ^^
const generator = ()*=> ... // err, *=3, still multiplying?
const generator=*()=> ... // err, ^^
const generator = *param => ... //err, "param" is not fixed word

Acesta este ceea ce poate fi marele motiv pentru care nu au implementat generatorul în legătură cu funcția săgeată.


Dar, dacă aș fi fost unul dintre ei, m-aș fi putut gândi astfel:

const generator = gen param => ... // hmm, gen indicates a generator
const generator = gen () => ... // ^^

Asta se simte ca și cum am avea o funcție asincronă:

const asyncFunction = async () => ... // pretty cool

Pentru că, în cazul unei funcții normale, funcția asincronă există, așa că funcția săgeată îl folosește – async () => este posibil să pară async function().

Dar, nu există un cuvânt cheie de genul gen sau generator și, din păcate, funcția arrow nu îl folosește.

În concluzie:

Chiar dacă doresc să implementeze generatorul în funcția arrow, cred că trebuie să regândească sintaxa generatorului în core js:

generator function myfunc() {}
// rather than
function* myfunc() {} // or, function *myfunc() {}

Și aceasta va fi o mare gafă. Deci, păstrarea funcției arrow în afara generatorului, este destul de mișto.


În urma comentariului lui @Bergi:

Nu. Funcțiile săgeată ar trebui să fie ușoare (și nu au un .prototype, de exemplu) și adesea one-liners, în timp ce generatoarele sunt cam opusul.

Voi spune că scopul generatorului de utilizat este run-stop-run și, prin urmare, nu cred că trebuie să ne intereseze prototipul, lexicalul this etc.

Comentarii

  • S-ar putea lua în considerare și opțiuni exotice, cum ar fi () ~> { yield 'a'; yield 'b'; }. Ca să fiu sincer, îmi plac tildes. –  > Por Gershy.
  • @Gershom Acesta este modul în care limbaje de programare precum Perl merg total greșit –  > Por Sapphire_Brick.
Gourav Makhija

În acest moment nu puteți, dar în viitor s-ar putea să fiți, deoarece TC39 release propunerea pentru același lucru în octombrie 2019, care se află în etapa 1.

coolreader18

Știu că este foarte târziu, dar un alt motiv posibil ar putea fi sintaxa. poate (*() => {}) funcționează, dar ce se întâmplă cu (9 ** () => {})? Este vorba de 9 la puterea unei funcții săgeată, care returnează NaN, , sau este de 9 ori o funcție săgeată generatoare, returnând de asemenea NaN? S-ar putea face cu o sintaxă alternativă, cum ar fi =>* așa cum a fost menționat de un alt răspuns aici, dar poate că s-a dorit păstrarea coerenței sintaxei funcției generatoare (de ex. function* () {} și { *genMethod() {} }) atunci când a fost implementată. Nu este o scuză prea mare, dar este un motiv pentru aceasta.

Comentarii

  • :+1: pentru asteriscurile duble… Un tip JS de școală veche aici. Cine spune că nu poți învăța un câine bătrân trucuri noi :joy: –  > Por Shanimal.
  • Singurul motiv pentru care nu o fac, este pentru că realizarea parser-ului este dificilă. Este perfect posibil și nu necesită niciun compromis în sintaxă. –  > Por Jason McCarrell.
  • @JasonMcCarrell Dacă le păsa suficient de mult să nu facă parserul prea complex, atunci poate că Brendan Eich ar fi trebuit să pună Scheme în browser. –  > Por Sapphire_Brick.
Julius Baltrušaitis

Există o soluție de rezolvare frumoasă cu redux-saga

import { call, all } from 'redux-saga/effects';

function* gen() {
   yield all([].map(() => {
      return call(....);
   }));
}

Comentarii

  • De unde știm că OP folosește Redux? –  > Por Maros.