On Mon, Oct 21, 2013 at 10:28 PM, Nathan Wall <nathan.w...@live.com> wrote:
> > Allen Wirfs-Brock wrote:
> > Actually, this is a good point. As currently specified Object.assign
> > of with an own __proto__ property on the RHS object will trigger a
> > [[SetPrototypeOf]] on the LHS object. Is that what we want. It is a
> > direct fallout of specifying Object.assign as the equivalent of a
> > sequence of property assignments from the RHS to the LHS. "__proto__"
> > could be special cased. But should it?
> >
> > Object.mixin doesn't have this issue because, as Rick points out, it
> > uses GetOwnProperty/DefineProperty instead of Get/Set.
> >
> > Anybody want to argue that Object.assign shouldn't trigger
> > [[SetPrototypeOf]]?
> >
> > Allen
>
> 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]]`. Any number of accessor
> properties could do weird things:
>
> Object.defineProperty(Object.prototype, 'bloikle', {
> set(value) { Object.freeze(this); }
> });
>
> // Somewhere else far off in the code...
> Object.assign(foo, { bloikle: 'bar' });
>
> // Now foo is strangely frozen...
>
> For consistency, `__proto__` shouldn't be hidden from `Object.assign`.
>
Agreed.
> 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__);
>
> Exploring other options.. A possible alternative consistent option would
> be to expose some mechanism to hide properties from `Object.assign`, so
> that the bloikle property could be hidden in the above... Doing this well
> would probably require a way to make it work cross-realm, which at first
> thought sounds pretty difficult. And it probably wouldn't play nice with
> the above `info` example.
>
> I think I agree with Andrea on this. Should `Object.assign` be left out
> of ES6 for libraries to implement?
The point of adding Object.assign in ES6 was to pave the wide and heavily
trodden cowpaths that exist in libraries. As a built-in, the implementation
can be optimized in ways that would not be possible in library code.
... 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".
Rick
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
