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,
On Apr 20, 2015, at 8:55 AM, a.d.be...@web.de wrote:
Hello!
In
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-execution-contexts,
a paragraph reads:
| Transition of the running execution context status among execution
| contexts usually occurs in stack-like last-in/first-out
Hello!
In
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-execution-contexts,
a paragraph reads:
| Transition of the running execution context status among execution
| contexts usually occurs in stack-like last-in/first-out manner.
| However, some ECMAScript features require non-LIFO
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
19 matches
Mail list logo