super.prop assignment can silently overwrite non-writable properties

[Allen Wirfs-Brock]

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