Minimalist Classes

Axel Rauschmayer axel at
Wed Nov 2 05:34:50 PDT 2011

The new more object-literal-style syntax is great. "private" sticks out a bit, but it’s not a deal-breaker. It could even be good for the code if it had to appear at the beginning (kind of like a section). Such a section would be great for object literals, too. Maybe we can find a syntax that works for both (as in future-friendly)!

>> And if we're trying to emulate classical OO, then how about just dropping the ability to define data properties on the prototype.
> I am all for that! I kept it for parity with jashkenas's three.js example, but the r, g, and b props there are vacuous default proto-props (ditto the Monster example's proto var and const).

Great great idea! Very newbie-friendly. The error message could tell you: put those properties into the constructor.

>> Your private instance variables are quite interesting.
> Yes, that is a missing ingredient in most proposals we've seen.


>> 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 people have certain expectations for how property access looks (and JavaScript is a better language for it; I don’t like how Java instance properties become part of the local scope). My guess: The expectation would be either one of two notations.

    this at name, other at name
    this. at name, other. at name

>> What about just a dot with nothing on the left hand side?  Can '.foo' be shorthand for ''?  Or are there grammatical issues with that?
> That could work with [no LineTerminator here] restriction on the left, which is awkward -- it mandates manual semicolon insertion of you assign .foo = bar after a baz() statement. We thought about this in consider how to reform with, but that's a dead end.
> Another sigil is hard to justify for the this.publicProp case, and for dyadic methods, etc., other.publicProp is how you spell it -- the dot, I mean. So one would want this.publicProp anyway. Between this consideration and the preference for private, I'm fine stopping with @ for private.

I think the namespacing via this is a feature, it give the code a nice uniform look:
    if ( ===


Dr. Axel Rauschmayer
axel at


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

More information about the es-discuss mailing list