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?

(You don't end up in 9.1.9 step 7 in the above case, because 4.d.i first
sets ownDesc to a data descriptor. This falls into step 5. In step 5.c. the
existingDescriptor will be the accessor. The new step 5.e.i then returns
false rather than checking whether existingDescriptor.[[Set]] is callable)

Cheers,
Tom

2015-04-21 5:25 GMT+02:00 Kevin Smith <zenparsing at gmail.com>:

> 5.e If *existingDescriptor* is not *undefined*, then
>>        i.   If IsAccessorDescriptor(*existingDescriptor*), return *false*
>> .
>>        ii.  If *existingDescriptor*.[[Writable]] is *false*, return
>> *false*.
>>        iii.  Let *valueDesc* be the PropertyDescriptor{[[Value]]: *V*}.
>>        iv.  Return *Receiver*.[[DefineOwnProperty]](*P*, *valueDesc*).
>>
>> Lines 5.e.i and 5.e.ii are new additions.
>>
>
> Looks good to me.
>
> Thanks, Jason, for bringing this up!
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150421/e9add506/attachment.html>

FWIW, you can reproduce this test case without reference to the new `super`
syntax:

```js
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:

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

(You don't end up in 9.1.9 step 7 in the above case, because 4.d.i first
sets ownDesc to a data descriptor. This falls into step 5. In step 5.c. the
existingDescriptor will be the accessor. The new step 5.e.i then returns
false rather than checking whether existingDescriptor.[[Set]] is callable)