July TC39 meeting notes, day 2

Brendan Eich brendan at mozilla.org
Fri Aug 5 13:47:18 PDT 2011


On Aug 4, 2011, at 9:50 PM, Oliver Hunt wrote:

>> The grammar at http://wiki.ecmascript.org/doku.php?id=harmony:classes does not restrict Statement at all, currently. The return-the-result-of-an-expression restriction could be done grammatically but it is easier to do with semantics, prose in this case.
> 
> Indeed, one way to support this would be to have "modes" in the grammar.  If memory serves me correctly ANTLR supports such a concept, although I'm not sure how widely the idea ever spread.  Logically this is syntactic sugar around the large expansion of productions that would typically be necessary.

Parameterized productions are cool, but we have an LR(1) normative grammar and the reasons for keeping and validating LR(1) have been covered quite a bit, even this year, on es-discuss.

Generally, losing parameterization means duplication (the -NoIn vs. unsuffixed productions in ES1-5's grammar), or a semantic restriction (which can be an early error, e.g. return outside of a function, break outside of a loop, switch, or labeled statement, etc. -- even now we do not overcomplicate the grammar to forbid such things from parsing).


> I think part of what's confusing is I am still unclear whether class member functions are expected to apply to arbitrary objects.  My assumption has always been that member functions would throw when applied to an object of the wrong class, and I don't see a good argument for an instance of a class having (essentially) a mutable shape.

Please read the classes proposal. It's "just syntax", this is required for Harmony. We are not adding new runtime or (horrors) static semantics by which classes would make objects you could not make otherwise.

True, we could freeze -- 'const class' does some freezing and sealing -- but not by default. And we could insert |this| class checks in all methods, but those too are the exception, not the rule. I'm not sure 'const class' binds methods.

If we accept arrow function syntax, then using it in classes to allow this-binding is plausible, but this creates a bound method object per method per class instance. Heavy tax, akin to closuer pattern. Doing this avoids the |this| class check, of course.


> To me when a developer says "class ... {" they are opting out of "an object is a generic map" semantics, and actually want a fixed object shape.

Including the class prototype? I think not.

Anyway, classes that restrict instance and prototype shape, thereby allowing private foo to be referenced via 'foo', do not address the other.foo issue. Ruby after Smalltalk has *instance-private* instance variables, not class-private as we propose. That's why @x works in Ruby and you don't need other at x.

We agreed to class-private not instance-private, and that's what the harmony:classes proposal aims at (even with the straw and now burned private(this)/private(other) syntax). But per last week's meeting, we're going to take out private magic syntax from classes and try using private name objects: this[foo], other[foo] for private name object denoted foo.

I'm open to @ for private access, personally. (We can also support decorators using @ syntax if need be, but that's not currently proposed.) But any such @ for private access would also be an infix operator, so you could say other at foo. Private name objects used with or without magic syntax for privacy in class instance variables are class-private, not instance-private. You could use private name objects freshly generated per instance, too, if you wanted to -- but we aren't even deferring syntax for that use-case.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110805/5b2f54f9/attachment.html>


More information about the es-discuss mailing list