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 <tomvc...@gmail.com> 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 <dher...@mozilla.com> >> >> > 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@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
