In the simplest way can just desugar to Object.mixin(Foo.prototype,
Mixin1[, Mixin2, .., MixinN); before the class creation (methods of own
class's prototype should override mixins, but not the parent methods).
Although, form I see in the latest draft even Object.mixin(...) is still
under discussion.

Dmitry


On Thu, May 16, 2013 at 2:11 PM, Dmitry Soshnikov <
dmitry.soshnikov at gmail.com> wrote:

> Hey guys,
>
> Sorry for the random question (probably it was already discussed).
>
> What is a current state having mixins/traits syntax along with a class
> definition?
>
> Like:
>
> class Foo extends Bar {
>   use EventEmitter, CommonMethodsMixin;
>   ...
> }
>
> where mixins provided in "use" declarations are simple objects which are
> copied to the Foo.prototype. (with potential optimization of delegating to
> mixins).
>
> We currently use an extension in our pre-processing infrastructure, which
> does exactly what described above (so it's not that hard to have it as a
> sugar in local projects):
>
> class Foo extend Bar mixin(EventEmitter) { ... }, although "use" seems
> fits better and to have it on standard level is seems reasonable.
>
> Thanks,
> Dmitry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130516/4de9e4c0/attachment.html>

In the simplest way can just desugar to `Object.mixin(Foo.prototype, Mixin1[, Mixin2, .., MixinN);` before the class creation (methods of own class's prototype should override mixins, but not the parent methods).  Although, from what I see in the latest draft even `Object.mixin(...)` is still under discussion.