Traits - current state of discussion
The traits.js library is in great shape traitsjs.org. The traits
semantics it implements is wonderful < soft.vub.ac.be/Publications/2011/vub-soft-tr-11-15.pdf>, and has
been made precise. However, without platform support it suffers from, arguably, four problems:
- performance -- as with the objects-as-closure pattern which it generalizes, traits.js costs an allocation per method per instance.
- notation -- as a library, it lacks the syntactic affordances that similar abstraction mechanisms, like the upcoming minimal classes, are expected to provide.
- conflict detection -- it would be nice to catch unresolved conflicts earlier than instantiation.
- impedance mismatch with classes.
The reason we've adopted the minimal classes proposal into ES6 is to adopt only the agreed intersection of the various things people wanted classes to do, leaving room to grow back into all sorts of missing functionality post ES6. Traceur is an excellent vehicle to explore such extended classes experiments. If you wish to try growing classes back towards supporting traits, I suggest looking at strawman:classes_with_trait_composition, strawman:trait_composition_for_classes and strawman:syntax_for_efficient_traits
Note that none of these have been reworked to be consistent with the current ES6 minimal classes design.
2012/9/21 Aron Homberg <info at aron-homberg.de>
Does the strawman/traits_semantics document reflect the recent common understanding how traits should be implemented?
No: traits are not currently being considered for ES6. Instead, the committee chose to go for a more minimal approach that provides better support for current best practices and patterns based on prototypal (single-)inheritance.
As a meta-point, notice that the traits/semantics wiki page lives under the "strawman:" namespace. These are proposals that have not (yet) gained consensus. Proposals that have reached consensus in the committee live under the "harmony:" namespace, cf. < harmony:proposals>.
Once upon a time we actually had Traits in the pre-maxmin-classes implementation in Traceur. We've removed it as the class proposal is now radically different, but I'm hopeful that once classes are "baked", traits will be one of the important improvements we can add quickly.
Getting there requires that we have a solid proposal, so perhaps the first thing to do here is to look back at the trait syntax we had before, decide what you did and didn't like, and work with us to come up with a new straw-man for ES7. Once we've got something we like, we can prototype in Traceur.
Sound good?
2012/9/23 Alex Russell <slightlyoff at google.com>
Getting there requires that we have a solid proposal, so perhaps the first thing to do here is to look back at the trait syntax we had before, decide what you did and didn't like, and work with us to come up with a new straw-man for ES7. Once we've got something we like, we can prototype in Traceur.
Sound good?
Sounds great. What is the trait syntax you had before? It's no longer linked to from < code.google.com/p/traceur-compiler/wiki/LanguageFeatures>
please excuse me if this post is misleading - I'm new to this mailing list.
After implementing getter / setter methods (valid ES3 cross compile generator output) for classes in traceur-compiler I'm thinking about implementing traits. Therefore I'd like to know the current state of your discussions regarding how traits should look like. [1]
Does the strawman/traits_semantics document reflect the recent common understanding how traits should be implemented? I'm asking because the Traceur wiki says: "Traits have been removed to pave way for a class proposal everyone can agree upon." [2]
[1] strawman:traits_semantics [2] code.google.com/p/traceur-compiler/wiki/LanguageFeatures#Traits
Thank you and kind , Aron