ECMAScript.next: the “TXJS” update by Eich

Brendan Eich held a talk [1] at the TXJS conference in which he detailed the latest updates on ECMAScript.next. This post lists the highlights of his slides and adds a few explanations.

Approved for ECMAScript.next (look at the ECMAScript Wiki [2] for details):

• let, const, function are block-scoped [3]
• Destructuring assignment:

      let {x,y} = myPoint;
      let [s,v,o] = myTriple;
  

• Parameter default values:

      function f(x, y=1, z=0) { ... }
  

• Rest parameter:

      function g(i, j, ...r) {
          return r.slice(i, j);
      }
  

• Spread operator:

      let arr = [0,1,2,3];
      let obj = new MyConstructor(57, ...a);
  

• Proxies: Proxy.create(handler, proto)
• Weak maps: new WeakMap()
• Modules [4]:

      module NewMath {
          export function fast_sin(x) { ... }
      }
  

• Iterators, generators:

      function* gen() {
          yield 1;
          yield 2;
      }
  

• Array comprehensions:

      return [a+b for (a in A) for (b in B)];
  

• Binary data:

      const Point2D = new StructType({ x: uint32, y: uint32 });
      const Triangle = new ArrayType(Point2D, 3);
      new Triangle([
          {x:0, y:10}, {x:20: y:3}, {x:10, y:255}
      ]);
  

• Class literals have been accepted. They are syntactic sugar for creating a prototype and a constructor. Eich mentions that he in principle likes that class literals were accepted, but is still not completely happy, because in addition to making some things easier, they also add new complexity and don’t really feel “JavaScript-y” [this is me very freely paraphrasing him]. It is possible that things in this area will change again [5].
• Private name objects: a built-in module that provides unique naming for properties:

      module Name = require "@name";
      const key = Name.create("secret");
      function MyClass(privateData) {
          this[key] = privateData;
      }
      MyClass.prototype = {
          doStuff() { ... this[key] ... }
      };
  

• Quasi-literals [6]: enable embedded domain-specific languages. The basic idea is to make it easy to enter custom syntax which is parsed by a function (the quasi handler) to produce data. This custom syntax is entered as text, but expressions can be inserted. The text is given to the handler as a sequence of tokens. For each token, one can determine whether it came from literal text or from an expression. These tokens are thus very similar so a syntax tree, but there is no nesting. One can nest quasis, by putting them inside ${}, but then they will be evaluated before being passed to a handler. Having two types of tokens gives the handler the option to transform inserted values, e.g. to escape special characters. Example quasi literals:
  • Secure content generation (handler safehtml): safehtml`<a href="${url}">${text}</a>`
  • Text localization: var message = msg`Welcome to ${siteName}, you are visitor number ${visitorNumber}:d!`;
  • Query languages, e.g. one using CSS selectors: $`a.${className}[href=~'//${domain}/']`
  • Inserting literal text into regular expressions: re`\d+(${localeSpecificDecimalPoint}\d+)?`
  • Raw strings: raw`In JavaScript '\n' is a line-feed.`

From http://www.2ality.com/2011/06/esnext-txjs.html