Minimalist Classes

Brendan Eich brendan at
Wed Nov 2 11:16:14 PDT 2011

On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:

> On 11/1/11 11:53 PM, Brendan Eich wrote:
>> On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
>>> 1) Class bodies are new syntax, so you can introduce new keywords, right?  So 'prop' or 'proto'?  'static' puts a property on the class.  'private' puts a (private) property on the instance.  So 'proto' could put a property on the prototype.
>> Yes, but prefix keywords in front of every member? Too heavy. Labeled sections are problematic grammatically and most on TC39 hate 'em. prefixed braced sub-bodies over-indent.
>> There ought to be a sane unprefixed default. Then, though, we still have two choices:
>> (a) Data property initialiser syntax (x: v with comma separator).
>> (b) Assignment expression form (x = v with semicolon separator or terminator and some kind of ASI consistency).
>> Neither is great. I lean toward (b). You?
> I don't see why you can't use var syntax but with 'proto' as the keyword instead of 'var':

I lean toward (a) now. I've made my peace with object initialiser syntax -- but with the Cordoba extensions for classes and object literals, as discussed with Jeremy today.

>>> Your private instance variables are quite interesting.
>> Yes, that is a missing ingredient in most proposals we've seen.
> And inquiring minds want to know more about them.  I assume they're scoped to the entire class body, right?


> And they hoist to the top?

That's how we roll where possible.

>   Could they have initializers that were automatically included in the constructor?

I answered that in a gist comment. Yes, I like the CoffeeScript constructor(@x, @y){} shorthand. Dart picked up on it, but requires this. instead of @. I'll put it in the gist.

> A comment in your gist (lines 186-187) seems to say that with 'private x', we can use @x or this[x].  Is that really what you meant?

Sorry, not quite. I will fix that comment.

>   Plain 'x' is bound to the Name object and @x is the value of the property with that name?  Is x a variable?

x is a const binding in the "@ scope" of the class body. It does not collide with any lexically bound x (formal parameter name, e.g.). That's important -- see the Monster constructor with its name and health parameters and private property names.

So, o at x is *not* o[x] for such a private-declared x.

Some argue @ should work for any x, so if there were some x = "y" in scope, then o at x would be o[x] would be o.y. I think that's too error-prone. What if I typo @heath instead of @health and there's a non-private-declared heath in scope?

> Does this mean that the class desugars into something that has a let statement surrounding the all the methods?

No, because private x does not bind a lexical name 'x' usable freely.

private/@ is new, the semantics are a slight extension to today's, not desugarable without gensym. I'll consult with my semantic betters on this one.

>>> One nit: you're using @ as both a sigil in @name and as an operator in other at name.  I would expect other. at name instead.
>> No, it's a prefix operator if in operand context (like / starting a regexp), a binary operator in operator context (/ as division).
>> Trying to avoid .@ all over, and this.@ noise.
> I think ordinary unary @ would dominate and .@ would be relatively rare.  But when used, it would at least look like noisy property access rather than an email address.  My gut says that regularity of     syntax wins over conciseness and noise here.

Oh, I see -- you are suggesting @x as short for this. at x, and requiring other. at x for non-this-based references. That could work. IINM it even avoids the [no LineTerminator here] to the left of unary prefix @. Nice!

I hear you on the email thing. I'm big on grep, and I mourn the coming demise of

> Do you expect the performance of private property lookup to be equivalent to public property lookup?  That is will @foo take the same time as

That is a requirement in my view.


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

More information about the es-discuss mailing list