super, self, and sideways & durable vs. template

Brendan Eich brendan at
Mon Jun 13 12:24:23 PDT 2011

On Jun 13, 2011, at 10:38 AM, Bob Nystrom wrote:

> On Sun, Jun 12, 2011 at 2:17 PM, Brendan Eich <brendan at> wrote:
> But to use the prototypal pattern, you would want something that has been discussed a bit: class elements (class body elements) defining once-per-class-evaluation function, let, and const bindings not as properties, but as lexical bindings in the scope of the prototype methods and accessors.
> I worry about treating a class body like a block scope and allowing variable declarations inside it. The syntax is really close to declaring properties inside the class (which is mostly what classes are for) and I worry people will get confused.

Yes, this is my point too. I'm not actively endorsing declarations making temporaries in the class body, only pointing out how otherwise, declarations make lexical bindings -- not properties. Bit difference.

This suggests class body syntax should be sui generis. We should not cross syntax streams here.

> More so, if we allow that, it means a class body becomes "block-like". It'll be a lexical scope and you'll be able to declare variables in it. At that point, I fear people will start expecting any statement to work inside a class body. Once we open that can of worms, it gets really hard to find open syntactic space for the stuff we care about: being able to tersely declare class, prototype, and instance members.

I don't think it's quite that hard, if you recall Mark's analogy to module bodies. Module bodies may contain declarations and statements. Only those declarations prefixed by export carry extra semantics peculiar to modules.

So in principle class bodies could be like module bodies, but then you would definitely need public (or proto, or some such novel contextual keyword) in front of the distinguished declarations.

Requiring such prefixing is too verbose. Consider the Point class I showed.

Also, module-exported declarations are still truly lexical bindings, until you reflect on a module and it reifies at runtime as an object with the exports showing up as fixed properties. This is fine as a reflection interface, but it does not seem right for classes to make prototype properties use lexical binding syntax, and indeed the current proposal mostly does not do that (more below).

> As much as possible, I'd like to have a class body be just a collection of property definitions.

That is the other way to go: make the property definitions look more like object initialiser contents, but without comma separation.

However, the current proposal does this only for methods and accessors. For data properties (on the prototype, or on the class via static or a better prefix), what looks like an assignment expression, or a declarator-name and initialiser without a leading var-like keyword, is used.

> I find that simpler to understand and less likely to cause us to paint ourselves into some syntactic corner.

Simpler is better, until it's simplistic -- Einstein's Knife.

> I've raised the issue among a couple of people and threads (although possibly not here on es-discuss) of whether the class syntax should rather avoid using declaration syntax to bind prototype properties. Declarations otherwise create lexical bindings.
> Why not just declare them outside of the class?

Fair point. We don't strictly need class-body-local declarations. They fall out of the module analogy, but I've argued against that above.

If class body syntax is special to its context, even if it reuses some parts of object initialiser syntax (which reuses function syntax in part for accessors and methods), then what should the syntax for prototype and class data properties be?

Prefixing with public, static, const, etc. wants declaration syntax. Using initialiser extensions without comma separation -- meaning with semicolon termination -- seems weird too, but it's more consistent.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list