ECMAScript.next: TC39’s September 2012 meeting

By ss - October 21, 2012

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 considered for inclusion in ECMAScript 6. The latest decision was to instead use a function 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)
```
Another blog post explains how it works.

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.