Complete Minimal Classes

Brendan Eich brendan at mozilla.org
Fri Apr 6 19:40:45 PDT 2012


Russell Leggett wrote:
> However, that means if we take out arbitrary prototype properties, 
> we're back to a proposal which also hasn't reached consensus.

No proposal has. It's possible we'll get there either way, what is in 
max-min or in Kevin's gists (not far off). Neither addresses the 
sticking point that I heard in committee.

> As for your fourth, most controversial point, separating call and 
> constructor would diverge from the existing pattern. Number() and new 
> Number() always call the same function.

That's one pattern. The other is Date() vs. new Date(), Object(otherObj) 
vs. new Object(otherObj), and kindred warthogs.

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.

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.

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