Traits/Mixins for class syntax
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.
for what it matters, redefine.js already does exactly that. ( WebReflection/redefine#classes )
var Foo = redefine.Class({
extend: Bar,
mixin: [F, object, F2.prototype, Class3]
});
and yes, it makes perfect sense, specially for mixins such EventEmitter and similar
my 2 cents
Sure, this abstraction presents in almost any library related with classes sugar. I'm just curious whether it was even discussed here, and what is probability it can be included into this spec.
(Or maybe into ES7, no matter much yet; I still excluding the version that I'm asking a "stupid question" here -- as the reason why it's possible can be ignored).
Dmitry
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
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) {
...
}
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: ```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.
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.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/3d432bec/attachment.html>