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

Mark S. Miller erights at google.com
Thu May 19 15:43:28 PDT 2011


On Thu, May 19, 2011 at 3:08 PM, Brendan Eich <brendan at mozilla.com> wrote:
[...]

>
> You guys have been good sports, here is one last minor comment: The *
> ExportableDefinition* nonterminal produces this right-hand side:
>
>       Identifier = Expression ;                            // provided data
>
> which works perfectly after class (now static, hrm, two minor comments
> then ;-). But without a keyword in front,
>
> class Point {
>   x = 0;
>   ...
> }
>
> is a bit of a mystery.
>
> Is it an assignment expression-statement? No, no statements as *
> ClassElements*.
>
> Could it be creating a prototype property, as other unprefixed property
> initialisers such as get and set accessor declarations, and property
> initialiser extensions declaring prototype methods, do? Yes, that's the
> intent.
>
> But, I object (mildly), it does not *look* like a property initialiser. It
> looks like an assignment expression-statement.
>
> I see the dilemma: if you use colon, you walk into class body as object
> initialiser body, with comma separation, etc. If you use equal sign, you
> avoid that.
>
> But this is only for defining data properties on the class prototype. Is
> this case common? I can't think of a built-in class that has such a data
> property. It's very rare.
>
> So how about YAGNI -- leave this out, it won't be needed enough and one can
> always write C.prototype.x = 0 or Object.defineProperty(C.prototype, 'x',
> ...) after the class declaration has been evaluated.
>
> 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.

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.



>
> Ok, second minor point. At least dherman and I really dug the use of classwhere
> static is now specified. We avoid unwanted baggage from other (and static
> as in typing) languages. We point directly to the value of the binding
> created by the class declaration or evaluated from an anonymous class
> declaration: the constructor.
>
> Any strong reason why this change was made?
>

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.
    }

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.
    }




>
> Thanks for considering,
>
> /be
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110519/c4b7ae37/attachment.html>


More information about the es-discuss mailing list