ECMAScript.next: TC39’s September 2012 meeting

Thanks to Rick Waldron, we have a detailed account of the decisions regarding ECMAScript.next that were made by TC39 [1] during its meeting from September 18-20, 2012. This blog post summarizes and explains the highlights.

September 18

Highlights of the notes:

• The final draft of the Internationalization API (ECMA-402) has been approved (page with PDFs, HTML format). It will be submitted to the Ecma General Assembly for ratification. This API exists separately from ECMAScript and will be available for ECMAScript 5 or later.
• TC39 discussed River Trail [2], JavaScript language extensions for parallel programming. River Trail won’t be in ECMAScript 6, but ECMAScript 7 or later is possible.
• For a while, operators for batch-assignment and/or batch-definition were discussed. The latest decision was to instead use functions and to specify the properties to be added via an object literal. This kind of merging of two objects is already popular in third-party libraries. For example, Underscore.js has _.extend. ECMAScript 6 will have the function

  Object.assign(target, source)
  

  • Copy enumerable own properties from source to target.
  • Properties are read via [[Get]] and written via [[Put]]. That means that if target has setters, those will be invoked during copying.
  • Properties whose names are private symbols will not be copied.
  • Properties whose names are unique symbols will be copied.
  • Methods that use super will be configured so that they work properly in target. Such methods have a property that points to the objects they live in [3].
  • Returns: the modified target.
  There is only a single source, because an additional parameter with a property descriptor map may be added in the future. If you want multiple sources, you can use (source1 will be added to target first, overridden by source2 etc.):

      [source1, source2, source3].reduce(Object.assign, target);
  

  The difference between assigning and defining properties [4] continues to be a pitfall in JavaScript. For example, if you want to add a property foo to an object whose prototype has a setter foo then Object.assign() won’t let you do that, it will invoke the setter. An additional function Object.mixin() still has to be explored further to decide whether or not it should be added to ECMAScript 6. (Note: the name proposed in the meeting was Object.define(), but the function has since been renamed.)

  Object.mixin(target, source)
  

  • Copy all own properties from source to target.
  • Properties are copied by reading property descriptors from source and using them to define properties on target.
  • Properties whose names are private symbols will not be copied.
  • Properties whose names are unique symbols will be copied.
  • Methods that use super will be configured so that they work properly in target.
  • Returns: the modified target.
• Concise method definitions will be enumerable: ECMAScript.next offers a more compact way of defining methods in an object literal:

      obj = {
          theMethod(x, y) {
              return x * y;
          }
      };
  

  This is equivalent to:

      obj = {
          theMethod: function (x, y) {
              return x * y;
          }
      };
  

  This kind of concise method definition will be enumerable [5] in ECMAScript.next. Quoting David Herman: “Users expect that things they create to be enumerable and things that the platform provides to be non-enumerable.”

September 19

Highlights of the notes:

• More work on refining the proxy API.
• Property name objects [6] are now called “symbols”. That’s a good choice. Now you can say: Each property has a name. Such a name is either a string or a symbol.
• Syntactic support for symbols: There are two main pitfalls with symbols. First, they introduce an indirection that is difficult for many people to grasp and leads to verbosity:

      let sym = new Symbol();
      let obj = {
          // computed property name (abandoned feature!):
          [sym](x, y) {
              ...
          }
      };
      console.log(obj[sym](7, 5));
  

  Instead, the following would be easier to understand:

      private @sym;
      let obj = {
          @sym(x, y) {
              ...
          }
      };
      console.log(obj.@sym(7, 5));
  

  Second, if a an object or a class has many private properties, there is much redundancy, because you always have to declare a symbol before you can use it. The discussion of how to best avoid this redundancy is ongoing.

September 20

Highlights of the notes:

• Object.observe(): is a mechanism to provide built-in support for data binding. Data binding is used in many user interface frameworks (two examples: qooxdoo, SproutCore): If one changes the value of a model object property then that change will be immediately reflected in the user interface. Object.observe() will not become part of ECMAScript 6, but will probably appear in ECMAScript 7. A prototype for Chrome is currently being implemented.
• Thin arrow: Currently, only fat arrow (=>) functions [7] are to be included in ECMAScript 6. They provide a compact notation for non-method functions (with lexical this). Some people have expressed a desire for thin arrow (->) functions with dynamic this. However, consensus in TC39 was that the similar syntax would confuse users, they would have to decide which of the two arrows to use to achieve a given task. Traditional functions won’t go away and can be used instead of thin arrow functions. I welcome that decision, because users now have a clear and simple choice:
  • Need a method? Use the compact method syntax in classes and object literals.
  • Need a non-method function? Use a (fat) arrow function.
  That means that in the long run, we probably won’t have non-method functions any more that have this as an implicit parameter (to be handed in by call or apply). An additional explicit parameter will have to be introduced in these cases.
• Existential operator: CoffeeScript allows you to chain property accesses and to finish early if an undefined or null appears anywhere in the chain:

      result = obj?.prop1?.prop2?.prop3
  

  TC39 recognizes that such a feature is useful, but it does not have a high enough priority at the moment. Thus, it seems unlikely that it will become part of ECMAScript 6.
• Time table: the ECMAScript 6 specification should be feature-complete in January 2013.

References

1. ECMAScript: ES.next versus ES 6 versus ES Harmony [explains what TC39 is]
2. JavaScript: parallel programming via River Trail coming to Firefox
3. A closer look at super-references in JavaScript and ECMAScript.next
4. Properties in JavaScript: definition versus assignment
5. JavaScript properties: inheritance and enumerability
6. Private data for objects in JavaScript
7. ECMAScript.next: arrow functions and method definitions