On Mon, Oct 21, 2013 at 11:18 PM, Nathan Wall <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
