Pourquoi ES6 n'a-t-il pas de fonctions de flèche fine?

16

ES6 a ajouté des fonctions de flèche de graisse ( =>), qui ont deux différences majeures par rapport aux fonctions normales:

  • syntaxe plus courte (y compris retour implicite si vous utilisez un corps à expression unique)
  • hériter thisde la portée environnante

Ce sont deux fonctionnalités très utiles, mais elles me semblent complètement distinctes dans leur valeur et leur application - parfois je veux l'une, ou l'autre, ou les deux, ou aucune. Il semble étrange que si je veux utiliser une fonction de syntaxe courte, je dois également utiliser le thiscomportement -modifier. Et vice versa. Je ne vois pas pourquoi ces deux capacités sont implémentées comme un seul ajout au langage.

Que faire si je veux utiliser une fonction de syntaxe courte pour son retour implicite et sa brièveté (dans un contexte où un full function (..) { return ...}serait légèrement moins lisible), mais je veux utiliser thisdans ma fonction pour faire référence au contexte appelant? Il n'y a aucun moyen de le faire.

CoffeeScript a deux ->et =>fonctions de style, et apparemment ES6 a emprunté le =>style à partir là - bas. Ma question est donc la suivante: pourquoi ES6 n'a-t-il pas également emprunté le ->style?

javascript es6 callum
la source
Les fonctions de flèche de graisse ont d'autres différences, comme elles ne peuvent pas non plus se lier arguments.
DeadMG
Si parfois vous ne voulez que la portée environnante, vous pouvez toujours vous lier thisà la fermeture dans une déclaration de fonction complète. Ce n'est peut-être pas la partie qui vous préoccupe cependant.
Ben

Réponses:

25

Voir la proposition d'ajouter des fonctions fléchées: http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax 1

Ce qu'il dit, c'est:

Cependant, nous ne voulons pas de CoffeeScript ->, il est déroutant d'avoir deux flèches et dynamique cette liaison est une arme de poing souvent déclenchée.

Vous pouvez également voir une discussion sur une version précédente de la proposition qui avait également la syntaxe ->: https://esdiscuss.org/topic/arrow-function-syntax-simplified

Il semble se résumer à ce qui suit:

  1. Avoir deux syntaxes de flèches avec une sémantique subtilement différente augmenterait la complication et la confusion.
  2. La dynamique de cette liaison de fonction () et a ->été jugée rarement utile, et un foot-gun.
  3. Si vous avez vraiment besoin de dynamiser cette liaison, vous pouvez toujours utiliser function (), avoir une syntaxe de raccourci n'était pas très utile.
Winston Ewert
la source
1
+1. Notez spécifiquement que ES6 est la deuxième tentative d'introduction de ces fonctionnalités, qui étaient initialement prévues pour être incluses dans ES4, mais la spécification a été abandonnée lorsqu'il est devenu clair que les principales parties prenantes pensaient qu'elle était trop complexe et susceptible de briser la compatibilité descendante. Garder tout aussi simple que possible devait être un objectif important pour le comité cette fois.
Jules
1
Merci pour votre réponse mais je ne pense pas que cela la couvre. Moins ne signifie pas plus simple; Je dirais qu'il est plus complexe de basculer entre deux syntaxes de fonctions très différentes juste pour obtenir une logique de liaison différente (par rapport à la commutation d'un seul caractère). Avoir "plusieurs types de fonctions avec une sémantique variable" n'est pas une idée terrible; c'est exactement ce que nous avons en fait. Et je ne vois pas ce que la rétrocompatibilité a à voir avec tout ce dont nous parlons. Je ne suggère pas qu'ils auraient dû supprimer la prise en charge de la syntaxe de fonction classique, si c'est ce que vous voulez dire
callum
2
@callum, le consensus (au moins parmi les personnes qui prennent cette décision) est que le function()style de cette reliure était une erreur et une verrue sur la langue. S'ils le pouvaient, ils changeraient function()pour avoir la =>sémantique, mais ils ne le peuvent pas car cela romprait la compatibilité descendante.
Winston Ewert
2
@WinstonEwert, attendez-vous, dites-vous que les personnes qui auraient pris la décision auraient préféré pouvoir changer function()pour hériter thisde la portée environnante comme le =>fait le cas? Dans ce cas, ne ferait-on pas thissimplement référence à l'objet global partout? Ça a l'air bizarre. Où avez-vous entendu cela?
callum
3
Cela peut avoir une réponse acceptée, mais cela semble être une mauvaise conception de la langue. Si vous avez une langue qui nécessite une grosse flèche, une fine flèche devrait également être disponible. Le premier oblige tout le monde à commencer à penser en termes d'objets, tandis que le second reconnaît d'abord l'histoire des javascripts du design fonctionnel et le contexte différé.
Core