"Syntax for Efficient Traits" is now ready for discussion (was: Classes as Sugar is...)

Tom Van Cutsem tomvc.be at gmail.com
Tue Sep 14 01:56:46 PDT 2010


Hi Mark,

Thanks for kickstarting this proposal. Initial comments:

- The keyword 'mixin' could be confusing. It is used to express trait
composition, not mixin composition. A better alternative would be "compose".
If we want to stick to reserved keywords, "implements" seems the most
appropriate (although this similarly confuses trait composition with
interface implementation).

- I like your semantics of raising trait composition errors upon evaluation
of a (trait) class expression/declaration. As you note, typically most class
definitions will occur at top level, and composition errors can be early
errors. Yet it does not preclude nesting a (trait) class expression, such
that traits can enjoy the same flexibility as functions.

"These examples suggest that perhaps our syntax should implicitly compose
where it currently implicitly overrides. This is doable, but leaves open the
question of how to syntactically express an override."
=> In the original Smalltalk Traits, methods declared in the class always
implicitly overrode methods declared in traits. This keeps the model closer
to traditional OOP inheritance. I would not mind switching the default from
'override' to 'compose'. In that case, perhaps one could express overriding
by replacing the 'method' keyword with an 'override' keyword, as so:

class Foo(a,b) {
 mixin BarTrait(),
 override toString() { ... } // overrides BarTrait.toString if BarTrait
defines it
}

Perhaps the override modifier could even cause an error if there is no
method to override.

Cheers,
Tom

2010/9/14 Mark S. Miller <erights at google.com>

>
>
> On Mon, Sep 13, 2010 at 5:27 PM, Mark S. Miller <erights at google.com>wrote:
>
>> On Mon, Sep 13, 2010 at 5:18 PM, Oliver Hunt <oliver at 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.soshnikov at 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"?
>>
>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100914/cea2d909/attachment-0001.html>


More information about the es-discuss mailing list