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