@@new

[Brendan Eich]

Allen Wirfs-Brock wrote:
> Except in the current design there is no special reinterpretation of 
> the constructor method body semantics.  The constructor method 
> definition simply provides body of the constructor function and 
> semantically is exactly the same as the body that is provided in a 
> Function definition. See 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-classdefinitionevaluation 
> <http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-runtime-semantics-classdefinitionevaluation> and 
> in particular step 10 which calls 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-definemethod 
> <http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-runtime-semantics-definemethod> which 
> just calls 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-functioncreate <http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-functioncreate> . 
>  No special processing of the body anywhere along that path.  The only 
> special treatment prior to step 10 is about choosing a default 
> constructor body if a constructor method isn't provided in the class 
> declaration.

Fair point, things have changed. Still, here are some other bits of 
magic that make constructor(){} as ClassElement not just a method 
definition. Here's another:

* 'constructor' is not enumerable but methods are.

>
> It is an alternative syntax for providing a the body of a function, 
> but it has no unique semantics.  That seems significant to me.

Not so much to me, and one could argue for static [@@new](){} sugar 
similarly.

The most important thing here (I agree with Andreas R.) is -- if 
possible -- avoiding uninitialized object observability.

/be