ECMAScript.next: новые подробности, реагирующие на жалобы Дартса

18 сентября 2011 года Брендан Айх провел беседу в CapitolJS . В нем он рассказал больше о том, что будет в ECMAScript.next; как реагировать на жалобы, высказанные создателями Дартса; и RiverTrail , расширения JavaScript для параллельного программирования. Этот пост суммирует основные моменты первых двух тем.

Вещи, которые являются новыми относительно предыдущего покрытия 2ality
(которое вы должны прочитать в первую очередь):

• dom.js : В настоящее время DOM представляет собой API C ++, определенный в C ++ -центричном WebIDL (языке определения веб-интерфейса) и неуклюже привязанный к JavaScript. Это делает его медленным и сложным в использовании. Широко считается частью веб-стека, которая наиболее нуждается в исправлении [1]. Внедрение DOM в чистом JavaScript — это первый шаг к его улучшению. dom.js — это попытка полностью соответствовать спецификации WebIDL. И для этого нужны функции ECMAScript.next (Proxies и WeakMaps). Цитируя Эйха:
  

  
  Кстати, dom.js […] отлично работает, Дэвид Фланаган и Донован Престон, среди прочих, взломали его и (это важно) предоставили отзыв редактору WebIDL Кэмерону МакКормаку.
  

  Эпизод из «Минуты с Бренданом Eich» предоставляет справочную информацию о dom.js.

• Можем ли мы назвать это ECMAScript 6, пока? Следующая версия ECMAScript почти наверняка будет называться ECMAScript 6. Однако все же лучше использовать термин ECMAScript.next для набора функций, которые в настоящее время обсуждаются в вики Ecma TC39. Причина в том, что многое еще может измениться, и утверждение о том, что функция «в ECMAScript 6», может сбить с толку. Вместо этого Аллен Уирфс-Брок предлагает использовать эту фразу только для функций, которые присутствуют в проекте спецификации ECMAScript 6, который он в настоящее время пишет. Обратитесь к [2] за разницей между ECMAScript.next и ECMAScript Harmony (первый является подмножеством последнего).
• Частные свойства. Изначально частные свойства были частью буквального предложения класса, но теперь они обрабатываются комбинацией двух конструкций.

  Конструкция 1: частные имена объектов .

      module name from "@name";
      let key = name.create();
      function MyClass(privateData) {
          this[key] = privateData;
      }
  

  Частные имена скрыты от таких механизмов, как
  

  • Object.getOwnPropertyNames ()
  • для … в

  Конструкция 2: вычисляемые ключи в объектных литералах.

      const __password = Name.create();
      var obj = {
          [__password]: "my secret",
          unlock: function(pwd) {
              if (pwd === this[__password]) {
                  ...
              }
          }
      };
  

  Помещение выражения в квадратные скобки позволяет вычислить имя свойства в литерале объекта.

• Сокращенные функциональные выражения. В настоящее время существует два конкурирующих предложения.
  
  1. Синтаксис функции стрелки , вдохновленный CoffeeScript.

     let square = (x) -> (x * x); // expression body
     let range = (start, end) { // statement body
         var result = [];
         for(; start < end; start++) {
             result.push(start);
         }
         return result;
     };
     // fat arrow: use "this" of surrounding function
     callback = (msg) => ( this.vmail.push(msg) );
     

  2. Блок лямбды .

     let empty = {||};
     let square = {|x| x * x };
     
     // paren-free call to mimic control structure syntax.
     // Therefore: no semicolon at the end.
     let a = [1, 2, 3];
     let b = a.map { |e| e * e }; // [1, 4, 9]
     
     // Bonus: break, continue, return leave the block
     // (unlike in function expressions)
     Boolean.prototype.thenElse = function(ifTrue, ifFalse) {
         return this ? ifTrue() : ifFalse();
     }
     function getElement(arr, index) {
         (index < 0).thenElse {||
             return arr[arr.length + index];
         } {||
             return arr[index];
         }
     }
     

  Пока что TC39 только решил, что предложения являются взаимоисключающими, они оба не будут приняты. Но не ясно, будет ли кто-либо из них превращен в ECMAScript, и если да, то какой именно. Эйх предпочитает блокировать лямбды:

  
  Мне было ясно, что я предпочитаю блочные лямбды над стрелками из-за их добавленной семантической ценности и убедительных синтаксических имитирующих операторов управления. Приятно слышать, что @jashkenas [создатель CoffeeScript Джереми Ашкенас] согласен.
  

  […] Синтаксис JS не является проблемой для некоторых (возможно, многих) пользователей. Для других это трудности. Добавление block-lambdas помогает этой когорте, добавляет ценность для генераторов кода (см. Цели Harmony выше) и в целом улучшает язык, на мой взгляд. Он выиграл мой соломенный опрос в CapitolJS против всех стрел, более смелых альтернатив и ничего не делая.

  Я согласен с выбором Эйха. При использовании в качестве аргумента для функции лямбда-блок имеет лексическое «this» — лямбда-блок в блоке относится к объекту, для которого был вызван окружающий метод. Это устранит частый источник ошибок, который иногда даже обманывает экспертов. С блочной лямбдой новички в JavaScript будут автоматически делать правильные вещи.