In reading Rick's response, I noticed my comments were rather "messy" themselves.  Correcting for clarity.

> Given that `__proto__` is defined as an accessor on `Object.prototype`, 
> I think this should be expected. Any other setter defined on the object 
> or its prototype chain will be invoked in the same manner. It's 
> directly triggering `[[SetPrototypeOf]]`, it's just invoking the 
> `__proto__` setter which happens to trigger `[[SetPrototypeOf]]`.

Should say "It's **not** directly triggering `[[SetPrototypeOf]]`..."


> Plus, there's no reason this shouldn't work: 
> 
> var info = JSON.stringify( 
> '{ "__proto__": "A description of __proto__",' + 
> '"hasOwnProperty": "A description of hasOwnProperty" }' 
> ); 
> 
> var otherInfo = JSON.stringify( 
> '{ "propertyIsEnumerable": "A description of propertyIsEnumerable" }' 
> ); 
> 
> Object.assign(otherInfo, info); 
> console.log(info.__proto__); 
>

Should be `JSON.parse`, of course.

Rick Waldron wrote:
>> ... especially given that this `__proto__` dilemma feels "messy". 
> 
> The very last comment seems subjective, and my own subjective response 
> is that it's not "messy". 
> 

Although my message was objectively messy (referring to the mistakes above), you're right that the comment on the `__proto__` dilemma is subjective, but it makes some sense.  As Andrea pointed out, it may become common practice (at least among those who care about integrity) to want to leave out `__proto__` from assign-like operations, especially when the object to assign from comes from an unknown or (even moreso) an untrusted source -- the same as `hasOwnProperty` checks in `for..in`.

Maybe `Object.assign` should only write the property when the object being written to either doesn't contain it or it's a data property?  Should it really invoke any setters?

Too bad it's too late to bring that `__proto__` ship back to the harbor because that's where the real problem lies.

Nathan

In reading Rick's response, I noticed my comments were rather "messy" themselves.  Correcting for clarity.

> Given that `__proto__` is defined as an accessor on `Object.prototype`, 
> I think this should be expected. Any other setter defined on the object 
> or its prototype chain will be invoked in the same manner. It's 
> directly triggering `[[SetPrototypeOf]]`, it's just invoking the 
> `__proto__` setter which happens to trigger `[[SetPrototypeOf]]`.

Should say "It's **not** directly triggering `[[SetPrototypeOf]]`..."


> Plus, there's no reason this shouldn't work: 
> 
> ```js
> var info = JSON.stringify( 
> '{ "__proto__": "A description of __proto__",' + 
> '"hasOwnProperty": "A description of hasOwnProperty" }' 
> ); 
> 
> var otherInfo = JSON.stringify( 
> '{ "propertyIsEnumerable": "A description of propertyIsEnumerable" }' 
> ); 
> 
> Object.assign(otherInfo, info); 
> console.log(info.__proto__); 
> ```

Should be `JSON.parse`, of course.

Rick Waldron wrote:
>> ... especially given that this `__proto__` dilemma feels "messy". 
> 
> The very last comment seems subjective, and my own subjective response 
> is that it's not "messy". 


Although my message was objectively messy (referring to the mistakes above), you're right that the comment on the `__proto__` dilemma is subjective, but it makes some sense.  As Andrea pointed out, it may become common practice (at least among those who care about integrity) to want to leave out `__proto__` from assign-like operations, especially when the object to assign from comes from an unknown or (even moreso) an untrusted source -- the same as `hasOwnProperty` checks in `for..in`.

Maybe `Object.assign` should only write the property when the object being written to either doesn't contain it or it's a data property?  Should it really invoke any setters?

Too bad it's too late to bring that `__proto__` ship back to the harbor because that's where the real problem lies.