d at domenic.me (2015-02-17T18:10:06.451Z)
I'm using traits without any sort of problems in [es-class][1] and the key is to have an initialize method. It's actually IMO bad expectation to explicitly initialize a known constructor via a mixin, it makes it non portable and non reusable, correct? What Kevin suggested is indeed the way I've implemented them, I also didn't know that the chosen keyword for traits was mixin. Is this final decision? Thanks [1]: https://github.com/WebReflection/es-class
I'm using traits without any sort of problems in es-class [1] and the key is to have an initialize method. It's actually IMO bad expectation to explicitly initialize a known constructor via a mixin, it makes it non portable and non reusable, correct? What Kevin suggested is indeed the way I've implemented them, I also didn't know that the chosen keyword for traits was mixin. Is this final decision? Thanks [1] https://github.com/WebReflection/es-class On Fri, Feb 6, 2015 at 5:37 AM, Luke Scott <luke at cywh.com> wrote: > > On Feb 5, 2015, at 9:07 PM, Kevin Smith <zenparsing at gmail.com> wrote: > > >> Hopefully I’m wrong in that Foo.call(this) is illegal, but if it is, this >> is a devastating change, especially when traits are scheduled for ES7 or >> later. >> > > Class constructors will now throw when called. > > The changes to classes were fundamental but necessary to support > subclassing of builtins (and future extensions to classes). > > For mixins, can you move the initialization logic into a method (or a > static method), instead of having it in the constructor? > > class M() { > // methods > static initialize(obj) { } > } > > function ctor() { > M.initialize(this); > } > > // etc. > > Is this a viable pattern for traits/mixins? > > > With the code example I provided Foo is the class, not the mixin. Foo > needs to be copied so traits can be added to it. > > Here’s an example: > > class Foo {} > class Fooy extends mixin(Foo, SomeTrait) {} > > “Foo” needs to be copied and the methods from SomeTrait needs to be added > to the copy’s prototype, which Fooy then extends. > > This is how you would traditionally copy a “class” (pre-es6 rev32): > > class Foo { > constructor() {} > } > function copy(classObject) { > function ctor() { > Foo.call(this); > } > ctor.prototype = Object.create(classObject.prototype); > ctor.prototype.constructor = ctor; > return ctor; > } > > Although, after some discussion in a 6to5 issue, this may (hopefully) be > legal: > > class Foo { > constructor() {} > } > function copy(classObject) { > return class extends classObject {}; > } > > As long as the prototype of the class can still be modified, that should > work. > > -- > Luke > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150206/8b71afa5/attachment.html>