github at esdiscuss.org (2013-07-12T02:27:22.553Z)
On May 20, 2013, at 2:42 PM, Allen Wirfs-Brock wrote:
>
> On May 16, 2013, at 5:11 PM, Dmitry Soshnikov 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?
>
> They aren't part of ES6. There have been past discussions about mixin support and they could be considered for a future edition
>
OK. Yes, this is type of abstraction which is very, very nice to have in any OOP-laguage to provide "horizontal" code-reuse, when reused methods are not logically fit to hierarchy concept (in addition to "vertical", aka "inheritance" code reuse).
So in the future, I believe ES will still adopt it. This abstraction (traits/mixins) is in many OOP languages.
>>
>> Like:
>>
> ```js
>> class Foo extends Bar {
>> use EventEmitter, CommonMethodsMixin;
>> ...
>> }
>> ```
>
> having you considered in ES6 exploiting the fact that what follow etends is an expression:
>
> ```js
> class Foo extends mixin(Bar, EventEmitter,CommonMethodsMixin) {
> ...
> }
> ```
>
Surprisingly, this is the exact form we're using in our infra today (and which I proposed internally to replace with "use" approach, since this expression with `mixin(...)` function seems to me "too library-like" rather than a language construct). Another disadvantage, we have to always import that `mixin(...)` module with `var mixin = require('mixin');` Although, I agree for class-AST-trasform we could generate import-code for it automatically.
Anyways, thanks for reply, Allen, appreciated. Thought, it's pity traits are not in ES6.
On May 20, 2013, at 2:42 PM, Allen Wirfs-Brock wrote: > > On May 16, 2013, at 5:11 PM, Dmitry Soshnikov 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? > > They aren't part of ES6. There have been past discussions about mixin support and they could be considered for a future edition > OK. Yes, this is type of abstraction which is very, very nice to have in any OOP-laguage to provide "horizontal" code-reuse, when reused methods are not logically fit to hierarchy concept (in addition to "vertical", aka "inheritance" code reuse). So in the future, I believe ES will still adopt it. This abstraction (traits/mixins) is in many OOP languages. >> >> Like: >> >> class Foo extends Bar { >> use EventEmitter, CommonMethodsMixin; >> ... >> } > > having you considered in ES6 exploiting the fact that what follow etends is an expression: > > class Foo extends mixin(Bar, EventEmitter,CommonMethodsMixin) { > ... > } > Surprisingly, this is the exact form we're using in our infra today (and which I proposed internally to replace with "use" approach, since this expression with mixing(...) function seems to me "too library-like" rather than a language construct). Another disadvantage, we have to always import that mixin(...) module with var mixin = require('mixin'); Although, I agree for class-AST-trasform we could generate import-code for it automatically. Anyways, thanks for reply, Allen, appreciated. Thought, it's pity traits are not in ES6. Dmitry