Classes as Sugar is now ready for discussion

Dirk Pranke dpranke at
Thu Sep 9 15:06:46 PDT 2010

As Brendan pointed out, the version evolution problem is nowhere near
a solved issue in language design; the only approaches I know of that
get close to it are the versioning of words in Forth and, depending on
how you look at it, the dynamic code loading mechanisms of Erlang
(and class loaders in Java). Insisting that we somehow come up with
a mechanism to prevent conflicts seems like a pretty high bar; I'd
like to hear more from people with such a view if that was indeed the
blocking objection.

-- Dirk

On Thu, Sep 9, 2010 at 3:13 AM, Tom Van Cutsem < at> wrote:
> There's no mistake that dedicated syntax for traits would help users and
> implementors alike. However, while I (or others) could definitely come up
> with a 'traits-as-sugar', or even a 'traits-as-a-new-value' proposal, that
> still wouldn't solve the version evolution problem associated with trait
> composition (or any other traditional inheritance mechanism). As long as
> this remains a deal-breaker, I don't think it's worth looking into
> alternative traits proposals.
> As Dave said, traits.js is out there for people to experiment with. Any
> feedback on usability issues of the design in its current form are highly
> appreciated.
> 2010/9/9 David Herman <dherman at>
>> > Agreed; perhaps my question was not clear. If there was a Traits-like
>> > proposal that did include new syntax, would you be against it because
>> > you can implement something similar as a library without needing new
>> > semantics, or would you be more inclined to reserve judgement until
>> > you could actually review a proposal and see what the proposed
>> > benefits were?
>> The latter (speaking for myself, of course).
>> Dave
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at

More information about the es-discuss mailing list