On Mon, Oct 21, 2013 at 11:18 PM, Nathan Wall <nathan.wall at live.com> wrote:

> 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?
>

If this were how it was defined, I would say get rid of it and
practitioners will carry on using their own non-nanny implementations. If
it can't invoke setters then it loses properties like innerHTML.

eg.

Object.assign(div, {
  innerHTML: `<p>${name}</p>`,
  id: "an-id",
  dataset: {
    foo: 1,
    bar: 2
  }
});


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

It may be beneficial, in the long run, to make it painful to use __proto__.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131021/5ae6cd9f/attachment.html>

On Mon, Oct 21, 2013 at 11:18 PM, Nathan Wall <nathan.wall at live.com> wrote:

> 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?

If this were how it was defined, I would say get rid of it and
practitioners will carry on using their own non-nanny implementations. If
it can't invoke setters then it loses properties like innerHTML.

eg.

```js
Object.assign(div, {
  innerHTML: `<p>${name}</p>`,
  id: "an-id",
  dataset: {
    foo: 1,
    bar: 2
  }
});
```

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


It may be beneficial, in the long run, to make it painful to use `__proto__`.