On Mon, Sep 13, 2010 at 5:27 PM, Mark S. Miller <[email protected]> wrote:
> On Mon, Sep 13, 2010 at 5:18 PM, Oliver Hunt <[email protected]> wrote: > >> >> On Sep 13, 2010, at 2:02 PM, Mark S. Miller wrote: >> >> On Mon, Sep 13, 2010 at 1:18 PM, Dmitry A. Soshnikov < >> [email protected]> wrote: >> >>> >>> I didn't finished a detailed reading yet, but from the brief scanning, >>> syntactically, I think *=>* and *trait class* are not needed. >>> >> >> * I used "trait class" rather than "trait" for two reasons: >> >> 1) Syntactic ambiguity fear. "trait" is not one of the identifiers >> reserved by ES5 or ES5/strict, and so I am not proposing that it be an >> ES-Harmony keyword. >> >> 2) More importantly, the object binds to the name it declares is not a >> trait but a function for making traits. >> >> >> I'd prefer 'class trait' which i think reads better, but i'm not sure how >> much i'm biased due to my desire to retain LL(1)-ness (I know that there is >> _some_ bias at least) >> > > Given that we're not treating "trait" as a keyword, when we see > > class trait(x, y) => {...} > > how would we know whether this is an anonymous TraitClassExpression on a > named ClassExpression for the class named "trait"? > Oops. That should be "...TraitClassExpression **or** a named ClassExpression..." > I agree we could make a special case for "trait" appearing in that > position, but is that more or less unpleasant that the lookahead needed to > distinguish "trait class"? > "that" should be "than" > > Also, to my ears, "trait class" reads like "adjective noun". A "class" is a > thing for making the kinds of things it describes. A "trait class" is a > thing which makes the traits it describes. For the same reason, several > people have suggested "const function" and no one has suggested "function > const". > > >> >> --Oliver >> >> > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
