Dlaczego ES6 nie ma funkcji cienkich strzałek?

ES6 dodał funkcje Fat-Arrow ( =>), które mają dwie główne różnice w stosunku do normalnych funkcji:

krótsza składnia (w tym niejawny zwrot, jeśli używasz treści pojedynczego wyrażenia)
dziedzicz thisz otaczającego zakresu

Obie są bardzo przydatnymi funkcjami, ale wydają mi się całkowicie odrębne pod względem wartości i zastosowania - czasami chcę jednej lub drugiej, albo obu, albo żadnej. Wydaje się dziwne, że jeśli chcę użyć funkcji krótki składni, ja mam również użyć thiszachowanie -modifying. I wzajemnie. Nie rozumiem, dlaczego te dwie możliwości zostały zaimplementowane jako pojedynczy dodatek do języka.

Co jeśli chcę użyć krótkiej funkcji składni do jej niejawnego zwrotu i zwięzłości (w pewnym kontekście, w którym pełny function (..) { return ...}byłby nieco mniej czytelny), ale chcę użyć thisw mojej funkcji, aby odwoływać się do kontekstu wywołującego? Nie ma na to sposobu.

Coffeescript ma zarówno ->i =>styl funkcje i najwyraźniej ES6 zapożyczył =>styl stamtąd. Więc moje pytanie brzmi: dlaczego ES6 również nie pożyczył tego ->stylu?

javascript es6

— kalus
źródło

Funkcje strzałek grubych mają inne różnice, tak jak nie mogą się wiązać arguments.

— DeadMG,

Jeśli czasami wszystko, czego potrzebujesz, to zakres otaczający, zawsze możesz powiązać thiszamknięcie w deklaracji pełnej funkcji. Jednak może to nie dotyczy Ciebie.

— Ben

Zobacz propozycję dodania funkcji strzałek: http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax 1

Mówi to:

Jednak nie chcemy CoffeeScript ->, mylące są dwie strzałki, a dynamiczne to wiązanie jest często strzelanym pistoletem.

Możesz również zobaczyć dyskusję na temat poprzedniej wersji wniosku, która również miała składnię ->: https://esdiscuss.org/topic/arrow-function-syntax-simplified

Wydaje się sprowadzać do następujących kwestii:

Posiadanie dwóch składni strzałek z subtelnie różną semantyką zwiększyłoby komplikacje i zamieszanie.
Dynamiczne to wiązanie funkcji () i ->było uważane za rzadko przydatne, a foot-gun.
Jeśli naprawdę potrzebujesz dynamicznego powiązania, nadal możesz użyć funkcji (), ponieważ składnia skrótu nie była zbyt pomocna.

— Winston Ewert
źródło

+1. Zwróć uwagę, że ES6 jest drugą próbą wprowadzenia tych funkcji, które pierwotnie planowano wprowadzić w ES4, ale specyfikacja została porzucona, gdy stało się jasne, że główni interesariusze uważają, że jest zbyt skomplikowany i może złamać wsteczną kompatybilność. Sprawienie, by wszystko było jak najprostsze, musiało tym razem być ważnym celem komitetu.

— Jules

Dzięki za odpowiedź, ale nie sądzę, że to obejmuje. Mniej nie oznacza prostszego; Twierdziłbym, że bardziej skomplikowane jest przełączanie między dwiema bardzo różnymi składniami funkcji, aby uzyskać inną logikę tego wiązania (w porównaniu do przełączania pojedynczego znaku). Posiadanie „wielu typów funkcji o różnej semantyce” nie jest strasznym pomysłem; to dokładnie to, co faktycznie mamy. I nie rozumiem, co kompatybilność wstecz ma wspólnego z tym, o czym mówimy. Nie sugeruję, że powinni usunąć wsparcie dla klasycznej składni funkcji, jeśli o to ci chodzi

— callum

@callum, konsensus (przynajmniej wśród osób podejmujących tę decyzję) jest taki, że function()styl tego wiązania był błędem i jest brodawką dla języka. Gdyby mogli, zmieniliby się function()na =>semantykę, ale nie mogą, ponieważ spowodowałoby to naruszenie kompatybilności wstecznej.

— Winston Ewert,

@WinstonEwert poczekaj, czy mówisz, że osoby podejmujące decyzję woleliby, gdyby mogły zmienić function()dziedziczenie thisz zakresu otaczającego tak jak =>robi? W takim razie czy nie thisodnosiłby się wszędzie do globalnego obiektu? Brzmi dziwnie. Gdzie to słyszałeś?

— callum

Może to mieć zaakceptowaną odpowiedź, ale wydaje się, że jest to kiepski projekt językowy. Jeśli masz język, który wymaga grubej strzały, powinna być dostępna również cienka strzała. Pierwszy z nich zmusza wszystkich do myślenia w kategoriach przedmiotów, podczas gdy drugi uznaje najpierw historię projektowania funkcjonalnego w javascript i odroczony kontekst.

— Core