On Sep 13, 2010, at 5:27 PM, Mark S. Miller wrote:
> On Mon, Sep 13, 2010 at 5:18 PM, Oliver Hunt <oli...@apple.com> 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
>> <dmitry.soshni...@gmail.com> 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"? 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"?
*face palm*
you are indeed correct :D
>
> 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".
I think this may just be a byproduct of us thinking about them in different
ways -- but that's moot as your above point is clearly correct :D
>
>
> --Oliver
>
>
>
>
> --
> Cheers,
> --MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
