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

Reply via email to