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
new:
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
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.
/be_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
