erights at gmail.com
Thu Mar 5 17:02:35 UTC 2015
If it were just a question of non-const-classes being too mutable, well,
they're everywhere already ridiculously too mutable in line with most
things in JS. It would be coherent to wait for const classes to repair the
mutability of the binding at the same time it repairs the mutability of the
prototype chain, etc.
However, the double-binding issue makes this weirder. If non-const-class
declarations were like non-const-function declarations, where there is only
one binding per defining occurrence, then I would fully agree. But this
issue of one defining occurrence creating two bindings that can diverge is
a new level of unpleasantness. I agree this calls for the issue to be fixed
now in ES6 if we can, for non-const-classes.
On Thu, Mar 5, 2015 at 8:46 AM, Kevin Smith <zenparsing at gmail.com> wrote:
> Just to be clear, this would make class declarations behave differently
>> from builtins, both the ES kind and the IDL kind, right?
>> I'm not saying that's a problem necessarily, but worth keeping in mind.
> Good point. I think that we need to be looking ahead toward const class,
> and leave ES6 class declaration bindings as is.
> es-discuss mailing list
> es-discuss at mozilla.org
Text by me above is hereby placed in the public domain
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss