Benjamin Gruenbaum (2015-02-12T20:19:49.000Z)
Sorry, forgot to CC the list

> From: Benjamin Gruenbaum <inglor at gmail.com>
> Date: February 12, 2015 at 22:19:14 GMT+2
> To: Domenic Denicola <d at 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 at domenic.me> wrote:
>> 
>> From: es-discuss [mailto:es-discuss-bounces at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150212/16a22039/attachment-0001.html>
d at domenic.me (2015-02-17T20:25:07.496Z)
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?