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

Mark S. Miller erights at google.com
Mon Sep 13 14:03:17 PDT 2010


On Mon, Sep 13, 2010 at 2:02 PM, Mark S. Miller <erights at google.com> 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.
>

Oops. Should be "the object bound to ..."


>
> * I introduced "=>" to disambiguate whether the "{" following the (trait)
> class head begins a block or a literal.
>
>
>
>>
>> *trait class EnumerableTrait() => {*
>>
>> instead better:
>>
>> trait Enumerable {
>>
>
> Enumerable is a function for making traits. Your syntax suggests that
> Enumerable is itself a trait.
>
> Without the "=>", how do we know that the "{" begins a literal rather than
> block? (See the second TraitBody production).
>
>
>>
>> *class Interval(min, max) => {*
>>
>> instead better:
>>
>> class Interval(min, max) {
>>
>> or even (with initialize method)
>>
>> class Interval {
>>   function initialize(min, max) {}
>> }
>>
>> Superfluous symbols are not needed.
>>
>
> Initialize methods are superfluous as well. Also, they introduce namespace
> confusion and re-initialization hazards.
>
>
>
>>
>> And still, don't forget about the (vertical) inheritance, i.e. class Foo
>> may *extends* Bar. If there will be no (delegation based) inheritance,
>> such classes won't be needed, because they will be just casual
>> pattern-factories. In addition, mixins/traits, being a horizontal
>> inheritance (the augmentation of the vertical code reuse) are also good to
>> have as delegation based. I think that you (and Tom) used statically
>> augmented (a method per instance) object not because you like it
>> ideologically, but because it's not possible to implement it cross-browser
>> in nowadays.
>>
>
> I'm not sure what you mean. Could you please expand and clarify the
> question? Thanks.
>
>
>
>>
>> Dmitry.
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>



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


More information about the es-discuss mailing list