An "extend" operator is a natural companion to <|

Brendan Eich brendan at
Tue Jul 19 15:45:31 PDT 2011

On Jul 19, 2011, at 3:13 PM, Allen Wirfs-Brock wrote:

>> The plain name; also looks like a useless expression-statement.
> When we talked some people pretty strongly felt that it was very desirable to be able to explicitly declare the intended per instance properties.  In addition to document purposes such declaration might, for example, be used for things like linting for this.mispellings in the body of the function.  Such explicit  declarations are probably essential if they are private properties.  But I don't see any problem with requiring inclusion of an initial value, even it it is going to be |undefined.|

It's fine to have privates declared, and I agree outside of the constructor is better than inside. But the syntax should not look like a useless identifier expression.

>> Whether they can be declared outside the constructor is a separate issue. Perhaps if they have constant or constructor-invariant initializers, they can be initialized where declared too.
> This seemed to be a big issue in the past that caused a lot of thrashing about how to put such declarations inside the constructor.  Backing off from that requirement would be helpful.

I don't think there was a requirement to put private instance property declarations inside the constructor. Rather, there were two bodies to choose from, and the class body was for prototype properties, absent some sectioning scheme such as Bob just proposed.

Now that Bob has proposed it (and we did discuss C++-style labeled sections, briefly, in the run-up to the May TC39 meeting, IIRC, but we skipped over that approach for some reason I don't recall), we can indeed avoid putting special syntax for public and private instance property declaration into the constructor body syntax.

This wins too because it lets constructor be a method like any other, syntactically.

>> But declarations should look different from expressions. The alternative we keep returning to is the property assignment sub-grammar of object literals, which would want
>>   new:
>>     numAttacks: 0;
>> with a semicolon not a comma.
> some thoughts -- why does the punctuation following the new (or class or prototype or whatever).  For example, what about
>    --new--
>      numAttacks: 0;
> that looks more distinctly like a section break and different from a property name (and otherwise how would one define a property name new or class or prototype or private?)

Good point, I should have seen that one coming. The private and class names being reserved words may have caused false hope that they could not be used as property names, but ES5 allows them -- same with new.

At this point, I'm going to withdraw the 

     numAttacks: 0;

idea, in favor of the assignment expression-statement form Bob sketched.

> Also, why ; instead of , like in object literals

We've been over this before: because methods have braced bodies that should not require either ; or , to be separate from adjacent methods. A class body is not an ObjectLiteral grammatically. We do not want to require

  class C {
    m1() {...},
    m2() {...},
    m3() {...}

when top level functions do not need any such comma separation.

>  (alternatively could we allow use of ; as a separator in object literals).

No one is looking for that extension.

>  It seems desirable to have consistency of property definitions between object literals and class declarations.

I don't agree. A class body is not an object literal, even if the method syntax is very close to the proposed method-in-object-literal syntax. Trying to make a class body be an object literal imposes ugly, undesirable, and likely-to-be-forgotten extra separator or even terminator punctuation (; or,  -- doesn't matter).

Method bodies are braced and, like function declarations in ES1-5, do not require gratuitous ; or , termination or separation from following source elements.

This means data property declarations in a class *do* need some kind of termination, and the obvious candidate for parallelism with function declarations is the semicolon.

From this, I concede that data property declarations in a class should not try to look like property assignments (key: value) in an object literal.

But I'm stil not happy about assignment-expression appearances. It's simply the lesser evil at this point, in my view.

The name; form, sans initialiser, is just wrong, so I agree we can mandate an explicit initialiser, even if undefined.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list