d at domenic.me (2015-05-01T13:05:37.650Z)
On Apr 21, 2015, at 12:31 PM, Tom Van Cutsem wrote:
> However, I'm not sure the new step 5.e.i. is correct: why abort the [[Set]] when the existing descriptor is an accessor? If it has a setter, it seems to me the setter should be run. Testcase:
Yes, I considered that possibility in deciding upon the proposed change. The reason I error out if the Receiver property is an accessor is because I think the most likely way this scenario will occur is when that that access includes a `super.prop` assignment. That would result in an infinite [[Set]] recursion. For example:
```js
var y = {
__proto__: x,
set prop(v) {
// ...
super.prop = v;
}
};
y.prop = 42;
```
On Apr 21, 2015, at 12:31 PM, Tom Van Cutsem wrote: > FWIW, you can reproduce this test case without reference to the new `super` syntax: > > ``` > var parent = {}; > var x = Object.create(parent, { > prop: { value: 1, configurable: true, writable: false } > }); > > Reflect.set(parent, "prop", 2, x); // expected false, but under current semantics will return true > ``` > > However, I'm not sure the new step 5.e.i. is correct: why abort the [[Set]] when the existing descriptor is an accessor? If it has a setter, it seems to me the setter should be run. Testcase: > > ``` > var parent = {}; > var v = 1; > var x = Object.create(parent, { > prop: { get: function() { return v; }, set: function(n) { v = n; }, configurable: true } > }); > > Reflect.set(parent, "prop", 2, x); // under Allen's proposed changes, this will return false while I think it should just call the setter? Yes, I considered that possibility in deciding upon the proposed change. The reason I error out if the Receiver property is an accessor is because I think the most likely way this scenario will occur is when that that access includes a `super.prop` assignment. That would result in an infinite [[Set]] recursion. For example: ``` var y = { __proto__: x, set prop(v) { // ... super.prop = v; } }; y.prop = 42; ``` Allen