Почему у ES6 нет функций тонких стрелок?


16

В ES6 добавлены функции жирной стрелки ( =>), которые имеют два основных отличия от обычных функций:

  • более короткий синтаксис (включая неявный возврат, если вы используете тело с одним выражением)
  • наследовать thisот окружающей области

Обе эти функции очень полезны, но мне кажутся совершенно разными по своей ценности и применению - иногда я хочу одну или другую, или обе, или ни одну. Кажется странным, что если я хочу использовать функцию с коротким синтаксисом, я должен также использовать thisповедение -modifying. И наоборот. Я не понимаю, почему эти две возможности реализованы как одно дополнение к языку.

Что если я хочу использовать функцию короткого синтаксиса для ее неявного возврата и краткости (в некотором контексте, где заполнение function (..) { return ...}будет немного менее читабельным), но я хочу использовать thisв своей функции ссылку на контекст вызова? Там нет никакого способа сделать это.

У CoffeeScript есть ->и =>функции стиля, и, очевидно, ES6 заимствовал =>стиль оттуда. Итак, мой вопрос: почему ES6 также не позаимствовал ->стиль?


Функции жирной стрелки имеют и другие отличия, например, они также не могут связываться arguments.
DeadMG

Если время от времени все, что вам нужно, это окружающая область, вы всегда можете привязать thisк замыканию в полном объявлении функции. Возможно, это не та часть, которая вас беспокоит.
Бен

Ответы:


25

Смотрите предложение по добавлению функций стрелок: http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax 1

Что это говорит:

Тем не менее, нам не нужен CoffeeScript ->, сбивает с толку наличие двух стрелок, и динамическое связывание - это часто используемый пистолет.

Вы также можете увидеть некоторые обсуждения предыдущей версии предложения, которая также имела синтаксис ->: https://esdiscuss.org/topic/arrow-function-syntax-simplified

Похоже, сводится к следующему:

  1. Наличие двух синтаксисов стрелок с едва различимой семантикой увеличит сложность и путаницу.
  2. Динамическое связывание функции () и ->редко считалось полезным, а также ножной пушкой.
  3. Если вам действительно нужно динамическое связывание, вы все равно можете использовать функцию (), так как использование синтаксиса ярлыков не очень помогло.

1
+1. Обратите особое внимание на то, что ES6 - это вторая попытка внедрения этих функций, которые изначально планировалось включить в ES4, но от спецификации отказались, когда стало ясно, что основные заинтересованные стороны считают, что это слишком сложно и может нарушить обратную совместимость. На этот раз важной задачей для комитета должно было быть максимально простое.
Жюль

1
Спасибо за ваш ответ, но я не думаю, что это покрывает это. Меньше не значит проще; Я бы сказал, что сложнее переключаться между двумя совершенно разными синтаксисами функций просто для того, чтобы получить различную логику этого связывания (по сравнению с переключением одного символа). Наличие «нескольких типов функций с различной семантикой» не является ужасной идеей; это именно то, что у нас есть на самом деле. И я не понимаю, как обратная совместимость связана с тем, о чем мы говорим. Я не предполагаю, что они должны были удалить поддержку классического синтаксиса функций, если это то, что вы имеете в виду
callum

2
@callum, консенсус (по крайней мере, среди людей, принимающих это решение) заключается в том, что function()стиль этого связывания был ошибкой и бородавкой в ​​языке. Если бы они могли, они бы изменить , function()чтобы иметь =>семантику, но они не могут , потому что нарушили бы обратную совместимость.
Уинстон Эверт

2
@WinstonEwert, подождите, вы говорите, что люди, принимающие решение, предпочли бы, если бы они могли перейти function()к наследованию thisот окружающего пространства, как это =>делает? В таком случае, не будет ли thisссылаться на глобальный объект везде? Звучит странно. Откуда вы узнали это?
Каллум

3
Это может иметь приемлемый ответ, но похоже на плохой языковой дизайн. Если у вас есть язык, требующий жирную стрелку, то должна быть доступна и тонкая стрелка. Первое заставляет каждого начать думать в терминах объектов, тогда как второе в первую очередь признает историю функционального дизайна javascripts и отложенный контекст.
Core
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.