Class double-bind

Allen Wirfs-Brock allen at
Mon Mar 2 22:15:14 UTC 2015

see belolw

On Mar 2, 2015, at 1:35 PM, Erik Arvidsson wrote:

> Classes are more similar to function expressions which do have an internal const binding.
> One way to desugar ClassDeclaration is to desugar it into a let binding for a ClassExpression. [1]
> let Foo = class Foo extends expr {};
> I would prefer if we didn't change the spec, not because I think it is too late (it is) but because having an internal const binding is good because then you can rely on that it will never change.
> [1] This is actually what we do in V8.
> On Mon, Mar 2, 2015 at 10:12 PM Mark S. Miller <erights at> wrote:
> All else being equal, your suggestion seems like the obviously right thing, on at least consistency and least surprise grounds.
> I know we discussed this. Anyone remember why we didn't do what Jason suggests? My memory of counter-arguments here is blank.
> On Mon, Mar 2, 2015 at 1:07 PM, Jason Orendorff <jason.orendorff at> wrote:
> Classes are specified to have an immutable inner binding even if they
> also declare a mutable lexical binding in the enclosing scope:
>     class Foo {
>         foo() {
>             // immutable inner binding 'Foo' is in scope here
>         }
>     }
>     // mutable lexical binding 'Foo' is in scope here
> Having two bindings can be tricky. Suppose I then do this:
>     Foo = wrapConstructorWithExtraLogging(Foo);
> Now the two bindings have different values. If one of Foo's methods
> does `new Foo`, we don't get the extra logging.

and conversely if we have something like this:

class Bar {
   constructor(n) {this.n=n}
   static get const() {return 42);
   op(x) { return new Bar(Bar.const )}

the inner workings of the class would get very screwed up if somebody did:
        Bar = { };

the chain of logic I apply for arriving at the specified behavior is:

1) There are many reasons a developer may want to refer to a class from within it's body and the obvious way of doing so should be reliable and tamper-proof.
2) This behavior of function declarations is actually quite astonishing and if we had a do over on FunctionDeclaration we would probably give it a local name binding just like function expressions (we might fight about it a while, but I'm pretty sure that's where we would end up).
3) Class declarations already differ from function declarations in a number of other ways, so class declaration consistency with function declaration on this one arguably buggy behavior is not a particularly strong position.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list