ES6 feature: computed property name about esprima HOT 11 CLOSED

Continuing on the discussion, some issues:

1. the value is alway computed. Therefore to me a computed flag does not feel like its referring to the value.
2. type Literal | Identifier | Expression will be simply Expression.

My suggestion will be:

interface ObjectExpression <: Expression {
    type: "ObjectExpression";
    properties: [ Property ];
}

interface Property {
    kind: "init" | "get" | "set";
    name: Expression;
    computed: boolean;
    value: Expression;
}

from esprima.

@ikarienator is the proposal here diff from SpiderMonkey? If so, file an issue at estree too please?

from esprima.

@ikarienator I agree with @mikesherov. Since computed flag is already becoming almost the de-facto standard, we should stick with this for now and brainstorm the further enhancement at estree.

from esprima.

This is only migrating the google code issue to here. I haven't checked estree yet.

from esprima.

I checked estree and it does not include much es6 contents. It does not include computed property name among other features. Why do we want to keep sync with it? https://github.com/shapesecurity/shift-spec/tree/es6 has a very complete and up to date definition of ES6 AST and very few issues if any. It is described in a compilable WebIDL. We can probably be more compliant to that than estree.

Are we trying to make the ES6 AST additive to the ES5 one? I'm not sure it's possible.

from esprima.

Let's discuss at the meeting on Wednesday then. The idea is compat with acorn and spidermonkey, several of which have living breathing es6 implementations in current versions.

from esprima.

@ikarienator Unfortunately that how's been implemented in the harmony branch so far. It seems to be less troublesome to support incremental addition, even it's not perfect, in the current situation.

from esprima.

Make sense. I will create issues in estree to address missing features that
has been implemented in harmony and master. Michael, what is the problem
preventing us from having a maximally additive ES6 AST in shift spec?
On Sat, Feb 14, 2015 at 13:28 Ariya Hidayat [email protected]
wrote:

@ikarienator https://github.com/ikarienator Unfortunately that how's
been implemented in the harmony branch so far. It seems to be less
troublesome to support incremental addition, even it's not perfect, in the
current situation.

—
Reply to this email directly or view it on GitHub
#1037 (comment).

from esprima.

BTW, the more proper old bug to be referred is this one: https://code.google.com/p/esprima/issues/detail?id=480. The corresponding harmony branch implementation is in commit 2bb17ef.

from esprima.

Thanks! Interesting... I may want move computed to the end of the finishProperty method.

from esprima.

There is also commit 54f49ada87, make sure we include the test case so that it is also covered.

from esprima.