Hi Kevin, 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 <zenpars...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
