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 Fri, May 17, 2013 at 10:01 AM, Andrea Giammarchi < [email protected]> wrote: > for what it matters, redefine.js already does exactly that. > ( https://github.com/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 > > > > On Thu, May 16, 2013 at 2:11 PM, Dmitry Soshnikov < > [email protected]> 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 >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
