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 <[email protected]> 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 <[email protected]>
> 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.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
