Herby Vojčík wrote:
Brendan Eich wrote:
I noted to Jeremy that even his classes gist snuck in a novelty or two
(the one I remember is class <expr> evaluating <expr> and copying it
somehow). We need to avoid novelty, while accepting that doing so is to
some extent future-hostile because present-friendly.
Could you please make this clearer, if you can? I do not understand it
fully, but what I understood so far (maybe mistakenly), I am afraid of.
See https://gist.github.com/1329619 lines 59-73.
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.
/be
/be
Thanks, Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss