> So there is code misusing Object.assign? This operation is _not_ for > inheritance, it's for batch property assignment of own properties.
Sorry, I assumed my point was clear from previous emails and used "fucking up
inheritance” as a reference. I meant not that it doesn’t create a new object
with the same inheritance tree, but that it ignores inherited properties in the
source when assigning them. Properties that when using the dot operator
would’ve been taken into account:
```
opts.silent
```
vs
```
opts = Object.assign({}, opts)
opts.silent
```
What’s the argument for not assigning all enumerable properties?
What’s the more important use case over those I’ve described in my previous
emails?
A.
On Feb 28, 2015, at 01:58, Rick Waldron <[email protected]> wrote:
>
>
> On Fri Feb 27 2015 at 5:31:51 PM Andri Möll <[email protected]> wrote:
>> `Object.assign` has **nothing to do with inheritance**, that's what I am
>> saying, not just supporting.
>
>> What is my personal position here is that `Object.assign` is the wrong
>> method/tool/function to do anything prototypal or classical inheritance
>> related.
>
>
> Are we entirely missing each other? I’ve said a few times now: it’s _none_ of
> the callee’s business if I use inheritance in my options, config, setup or
> any other plain object (one without behavior). Object.assign must honor that.
>
> I asked in my first email: What is the problem to which ignoring inherited
> properties is the solution to?
> If you have an argument that I haven’t refuted yet, please share.
>
> Just search GitHub’s code for assign usage and you’ll see it fucking up
> inheritance all over the place.
>
> So there is code misusing Object.assign? This operation is _not_ for
> inheritance, it's for batch property assignment of own properties.
>
> Rick
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
