I noted some open issues on "Classes with Trait Composition"

[Brendan Eich]

On May 19, 2011, at 3:43 PM, Mark S. Miller wrote:

> Or if you have a measured need based on some existing code, which I'd love to hear about: consider a prefixing keyword to make this look like an alternative to static x = 0.
> 
> Bob initially used "var" for that purpose. I do not object to having such a short prefixing keyword. But ever since the "let is the new var" revolution, whenever my eye notices a "var", my immediate reaction is "Danger danger warning warning. Once we can, figure out what this code is doing and rewrite as using 'let' or 'const'." Once ES-next is real and people really can get rid of "var"s, I hope this reaction will become more common. Looking for bad old code to fix? Grep for "var". Anything that habituates us to "var", reducing this alarm reaction, seems bad. 

I note that Declaration is produced by ExportableDefinition produced by PublicPrototypePropertyDefinition. That means let, const, function, and nested class are all possible in a class body.

http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#member_declarations_and_definitions is light on details, but I took these to define local bindings usable in other ClassElements -- not to create prototype properties (or any kind of property on an object).

Did I miss something?


> That said, if we decide we really want a keyword here and can't come up with a better alternative than "var", I probably could be talked into it. And I'm happy to see this added as an option to the strawman.

I'm still not sure we need to bind (enumerable by default, I just noticed -- a for-in hazard) data properties on the class prototype. If we do, I agree that var is not a good keyword to retask. We could make new keywords in context in the class body, I think. Dave mooted proto when we were talking about this. Just an idea.


> When I first saw this use of "class" I loved it. I never liked "static" and I disliked it even more after that. But the following syntactic case convinced me otherwise:
> 
>     class A {
>       class B {...}        // defines A.prototype.B as a class
>       class class C {...}  // defines A.C as a class
>       class D() {...}      // defines A.D as a function.
>     }
> 

Oh, so nested class declaration binds a prototype property? That is confusing. What do let, const, and function do? The other ClassElement production right-hand sides produce accessor and the new method property initialiser forms, not Declarations.


> by contrast, I don't think the following creates any similar confusion
> 
>     class A {
>       class B {...}        // defines A.prototype.B as a class
>       static class C {...} // defines A.C as a class
>       static D() {...}     // defines A.D as a function.
>     }

Given a nested class declaration binding a prototype property, I see your point. But is that nested class semantic really the right one, and how does it related to the other Declaration variants?

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110519/85e16753/attachment-0001.html>