Complete Minimal Classes

Herby Vojčík herby at
Sat Apr 7 01:20:36 PDT 2012

Brendan Eich wrote:
> I like Kevin's gist and want a private declaration too, both on its own
> (block-scoped so private foo is const foo = new Name('foo')) and as a
> special form in a class body, for body-scoped (fresh Name per class
> expression or declaration evaluation) class-private instance variable
> naming.

I don't think private in class-body is in any way special. As I see it, 
it's the exactly same 'private foo' which declares foo locally visible 
in the {} block with value of Name.create().

Seeing the other way, if you imagine 'private x' possible in object 
initializer, so you can write:
   let singletonCounter = {
     private c,
     @c: 0,
     inc() { ++this. at c; },
     val() { return this. at c; }

then 'private x' in class body is just straightforward syntactic mapping 
of this 'private x' into class-body syntax.

> None of this will kill us, max-min is just the smallest step, and one
> complaint has been about "doing too little". But the bigger complaint I
> saw was the one Waldemar raised (and has raised often): inability to
> declare something like
> sealed class Rect extends Shape {
> new(x, y, w, h) {
> super();
> // initialize x, y, w, h instance variables
> }
> ...
> }
> where, whatever the instance-property declaration and initialization
> syntax, instance properties cannot be used before initialized, and the
> instance is sealed by end of the new() method, *and* super() cannot add
> expandos. Therefore, users of new Rect(...) can be sure they have an
> object with only whatever Shape declared, plus x, y, w, h and any
> prototype methods -- and no other properties. You get a runtime error if
> you typo a property name.
> Whether 'sealed' would be required or not, depending on what we do in
> ES6 and later, I put it in to distinguish this Rect declaration from
> typical examples we've seen that do not care about sealing or throwing
> on typos.
> Clearly some careful barrier specification would be required to satisfy
> the no-use-before-init, no-expandos,
> typos-on-unmapped(by-prototypes-if-not-instance)-properties goals.
> The argument against max-min or other proposals that do not achieve
> these goals goes like this: supporting sealed classes later will make
> them less used or not used, when this is the sweet spot and
> justification for classes over extended object literals. Therefore doing
> only unsealed classes of the max-min or similar (per above) kind in ES6
> does too little and makes a permanent attractive nuisance.
> This is in addition to any future hostility (hard to prove there isn't
> any, and I think Waldemar backed down on that objection). This is the
> obstacle that I see. I think Allen's followup to the meeting notes
> captures it, but I wanted to emphasize the sealed, no-expandos,
> ivar-typo-checking goals.

Interesting. Thanks for information.

> I hope Waldemar will correct me if I've misunderstood.
> I'm not favoring anything by writing this, just trying to capture the
> constraints we face in trying to find consensus.
> /be


More information about the es-discuss mailing list