2015-04-21 22:15 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com:
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
2015-04-21 21:52 GMT+02:00 Kevin Smith zenpars...@gmail.com:
Another interpretation might be that since you've explicitly stated an
intention to bypass the receiver's setter, falling back to that setter
would be a bug.
No, that wouldn't be right. To clarify, Reflect.set takes the following
```
var y = {
__proto__: x,
set prop(v) {
// ...
super.prop = v;
}
};
y.prop = 42;
```
Assuming `x` here is the object where prop is bound to an accessor, can
you clarify how this would lead to an infinite recursion?
Assume let x = {}; (i.e. no
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
See also https://bugs.ecmascript.org/show_bug.cgi?id=3246#c3
I think the behavior where a data property can be installed accidentally
under an accessor property is crazy, but looks like I was overruled.
Dmitry
On Tue, Apr 21, 2015 at 4:18 AM, Caitlin Potter caitpotte...@gmail.com
wrote:
Right,
```
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
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);
It makes perfect sense for Object.defineProperty, but maybe not so much sense
for PutValue(). One idea was to just add an `return false if
existingDescriptor.[[Writable]] is false.` Before
receiver.[[DefineOwnProperty]]()`.
On Apr 20, 2015, at 8:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com
On Apr 20, 2015, at 12:39 PM, Jason Orendorff wrote:
On Mon, Apr 20, 2015 at 12:44 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
In the spec, 9.1.9 step 4.d.i. is where `super.prop = 2` ends up, with
O=X.prototype.
4.d.1 doesn't set the property, it just comes up with the property
On Apr 20, 2015, at 12:42 PM, Caitlin Potter wrote:
Oh — he’s right, ValidateAndApplyPropertyDescriptor won’t throw in the
example case, because the old descriptor is configurable. That’s kind of
weird.
It is kind of weird, but that was what TC39 decided on back when ES5 was being
On Apr 20, 2015, at 5:28 PM, Caitlin Potter wrote:
It makes perfect sense for Object.defineProperty, but maybe not so much sense
for PutValue(). One idea was to just add an `return false if
existingDescriptor.[[Writable]] is false.` Before
receiver.[[DefineOwnProperty]]()`.
yes,
Yes. The problem is not that DefineOwnProperty is not acting more like
assignment. The problem is that super.prop = x; is acting too much like
DefineOwnProperty and too little like assignment.
On Tue, Apr 21, 2015 at 3:54 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 20, 2015, at
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.
If the prop property accessed by super.prop is an accessor, super.prop = x;
should invoke its setter. super.prop should invoke its getter.
It does. This is about what happens when that property is a data property
doesn't exist. What happens when we do
On Apr 20, 2015, at 11:55 AM, Rick Waldron wrote:
On Mon, Apr 20, 2015 at 2:31 PM Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 20, 2015, at 11:11 AM, Rick Waldron wrote:
- It is a Syntax Error if ClassHeritage is not present and
HasSuperProperty of
Right, good point. No need to care about `existingDescriptor.[[Get]]` or
`existingDescriptor.[[Set]]`
On Apr 20, 2015, at 10:12 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Apr 20, 2015, at 6:52 PM, Caitlin Potter wrote:
If the prop property accessed by super.prop is an
On Apr 20, 2015, at 6:52 PM, Caitlin Potter wrote:
If the prop property accessed by super.prop is an accessor, super.prop = x;
should invoke its setter. super.prop should invoke its getter.
It does. This is about what happens when that property is a data property
doesn't exist. What
On Apr 20, 2015, at 6:21 PM, Mark Miller wrote:
If the prop property accessed by super.prop is an accessor, super.prop = x;
should invoke its setter. super.prop should invoke its getter.
It does. This is about what happens when that property is a data property
doesn't exist. What happens
On Apr 20, 2015, at 9:38 AM, Jason Orendorff wrote:
We're implementing `super` in Firefox, and ran across this surprising
behavior:
class X {
constructor() {
Object.defineProperty(this, prop, {
configurable: true,
writable: false,
Jason Orendorff schrieb:
[…] `super.prop = 2` ends up with O=X.prototype.
Uh, yes. And it should set `X.prototype.prop` to `2`, because that still
is writable and not affected by the attributes of `x.prop`. So I would
expect `x.prop` to still have the value `1`, shadowing the prototype
Uh, yes. And it should set `X.prototype.prop` to `2`, because that still is
writable and not affected by the attributes of `x.prop`.
So I would expect `x.prop` to still have the value `1`, shadowing the
prototype property.
I made this mistake as well, jorendorff@ pointed out that
On Mon, Apr 20, 2015 at 2:31 PM Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 20, 2015, at 11:11 AM, Rick Waldron wrote:
On Mon, Apr 20, 2015 at 1:45 PM Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 20, 2015, at 9:38 AM, Jason Orendorff wrote:
We're implementing
On Mon, Apr 20, 2015 at 2:42 PM, Caitlin Potter caitpotte...@gmail.com wrote:
Oh — he’s right, ValidateAndApplyPropertyDescriptor won’t throw in the
example case, because the old descriptor is configurable. That’s kind of
weird.
Yes, that's it. 9.1.6.3 step 8.a says that writability is
On Mon, Apr 20, 2015 at 12:44 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
In the spec, 9.1.9 step 4.d.i. is where `super.prop = 2` ends up, with
O=X.prototype.
4.d.1 doesn't set the property, it just comes up with the property descriptor
to use, if the `Receiver` does not already have
24 matches
Mail list logo
