On Tue, Jul 19, 2011 at 3:45 PM, Brendan Eich <bren...@mozilla.com> wrote:
> 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.
>
This is very cool. Yay for simplifying.
>
>
> 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.
>
I agree with all of this, 100%. :)
- bob
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
