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 

>> 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, 

>> 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 ES.next 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 

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.

es-discuss mailing list

Reply via email to