Sorry, forgot to CC the list
> From: Benjamin Gruenbaum <ing...@gmail.com> > Date: February 12, 2015 at 22:19:14 GMT+2 > To: Domenic Denicola <d...@domenic.me> > Subject: Re: about lightweight traits > > Those points are good, let me try to address them > > State - In other languages like C# and swift the issue with adding custom > state can be indeed very painful - in JS we can add a symbol on the object > mixed into or lazily creating it when the method first executes with a > default value. A Symbol can be used for separation of state from the object > if that is desired. I don't understand the argument about internal state - > how would a mixin be aware of a class's internal not relating to it state > anyway? > > Protocol - I agree here, but can't you call `.assign` in the constructor? > >> On Feb 12, 2015, at 22:11, Domenic Denicola <d...@domenic.me> wrote: >> >> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of >> Benjamin Gruenbaum >> >>> We have `Object.assign` that works fantastically for most classic trait use >>> cases. >> >> Well, actually, it works extremely poorly. The old (now dead or deferred) >> `Object.mixin`, once called `Object.define`, is a better fit. But it still >> fails to account for a couple things, off the top of my head: >> >> - Being able to add custom initialization logic to the class constructor >> when "mixing in" a trait. You can construct a custom protocol around this, >> but (a) that means the class you're mixing in to needs to be aware of the >> protocol; (b) everyone needs to agree on a protocol across the ecosystem. >> - Pretty much anything to do with private state doesn't work anymore.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss