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;
}

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

@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.

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

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.

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.

@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.

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 notifications@github.com
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).

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.

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

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