> See https://gist.github.com/1329619 lines 59-73.
Take away the idea of `class` as an operator (honest question: is programmatic construction of classes a use case that matters?) and it’s a very convincing minimal proposal. Then you have the option of adding support for private name objects and for constructor properties (via sections in the class declaration body and via Allen’s @ notation). > >> You say no brand new idea has chance to get in, since it is not known what >> it brings in the future? I am kind of person that believes in crazy (read: >> really different) ideas can push things through... but nevertheless, what >> did you mean more exactly by this paragraph? > > Classes "as sugar" were first proposed at the "Harmony" meeting in Oslo, July > 2008: > > https://mail.mozilla.org/pipermail/es-discuss/2008-August/003400.html > > Desugaring to existing JS syntax and semantics is good, it ensures library > interop and eases compilation (trans-compilation), it avoids risk taken on in > inventing new kernel semantics (we are way past the cut-off point for ES6). > Successful language designers are conservative even when making radical > founding design decisions. > > We could certainly add a great many novelties to classes: > use-before-definition errors for instance variables, separate instance > variables distinct from properties, etc. etc. TC39 prefers to avoid such > innovations. This doesn't mean we won't in due course add any such thing but > we won't do it in a big bad "scenario-solving" rush for classes. That seems like the right call. If anything, I would like to have support for classes that produce read-only instances and sealed instances (it’s still easy to accidentally add properties to an object) – both of which are tricky if subtyping is involved. I don’t see use-before-definition as too problematic, but there might be factors that I’m not aware of. -- Dr. Axel Rauschmayer [email protected] home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
