> On Feb 12, 2015, at 1:13 PM, Peter Seliger <[email protected]> > wrote: > > As for JavaScript, I strongly believe, Role based composition patterns > like Mixins or Traits should be function based.
I assume by this you mean that it shouldn’t be a construct and any special keywords. If that’s the case: This can be done now already. The problem is in order to do this you have to make a copy of the class you are extending w/ attached methods. And you cannot add traits without already extending an existing class. Assuming of course if you want to keep those definitions at the top instead of the bottom. Adding a “trait” construct along with a “mixin” or “use” keyword inside class / trait makes them more intuitive to use. > Whereas the widely used purely object based approach (together with > some copy mechanics provided by one of the several [extends] > implementations) does still work for Mixins, it is going to fail with Traits. > > Traits have to provide/implement functionality for conflict resolution of > methods, for requiring and for excluding them. For JavaScript this can > be achieved easily by just making use of the module pattern and another > function based mixin, that does provide those mentioned composition > methods. It doesn’t have to. Conflicts can be a fatal error at definition. There is no need to overcomplicate traits to this extent just because other languages do so. If a conflict does occur it’s likely due to a trait being too large and a sign that the functionality should be decomposed into more traits. A trait differs from a mixin by being able to ask the question “does this class/trait have this trait”. Conflict resolution is a “feature” that needlessly over complicates traits to the point where they become little different from multiple inheritance. — All IMO of course. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
