Classes as Sugar is now ready for discussion
P T Withington
ptw at pobox.com
Thu Sep 9 05:19:23 PDT 2010
On 2010-09-09, at 06:13, Tom Van Cutsem 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
I have on my to-do list to try re-casting the OpenLaszlo class framework as traits. Of the proposals for better class support in harmony, traits seems the most feasible to me for my work (we already translate to Ecmascript 3 and Actionscript 3). Clearly, I've got to actually implement it to test that theory.
I certainly don't know any solution to the version evolution problem. AFAIK, it's why no one uses DLL's any more (or if they do, each app ships with its own private copy of every DLL it depends on).
It's great that we can experiment with Traits without standardizing. It would be a shame to end up standardizing on an inferior proposal because of that feature of Traits.
More information about the es-discuss