getOwnPropertyDescriptor side effects

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

getOwnPropertyDescriptor side effects

Raul-Sebastian Mihăilă
Do you mean that an implementation is allowed to return an exotic object from the Error constructor?

https://tc39.github.io/ecma262/#sec-error-message

The Error constructor calls OrdinaryCreateFromConstructor in step 2.


According to its definition, OrdinaryCreateFromConstructor creates an ordinary object.

Not returning an ordinary object from the Error constructor is non-conformant and, assuming that conformance is a requirement for V8, it's a bug.

Just because an implementation adds a non-standard property to an ordinary object, even if its value is an exotic object, it doesn't turn the ordinary object into an exotic object.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Boris Zbarsky
On 1/10/17 2:10 PM, Raul-Sebastian Mihăilă wrote:
> Do you mean that an implementation is allowed to return an exotic object
> from the Error constructor?

No, I'm saying some implementations do that, because they want to
implement a non-standard "stack" property and the only way to get
reasonable behavior (as those implementations define "reasonable") for
it is to have the object be an exotic object.

There are other implementation strategies for "stack" that don't involve
an exotic Error object, of course (e.g. SpiderMonkey implements it as an
accessor property on Error.prototype).  They have their own tradeoffs,
though.

> Not returning an ordinary object from the Error constructor is
> non-conformant and, assuming that conformance is a requirement for V8,
> it's a bug.

Sure, just like arguably the presence of the "stack" property to start
with is a bug, because per spec it's totally unexpected.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Michał Wadas

Implementations are allowed to extend objects. Otherwise presence of global console would violate spec...


On 10/01/17 20:21, Boris Zbarsky wrote:
On 1/10/17 2:10 PM, Raul-Sebastian Mihăilă wrote:
Do you mean that an implementation is allowed to return an exotic object
from the Error constructor?

No, I'm saying some implementations do that, because they want to implement a non-standard "stack" property and the only way to get reasonable behavior (as those implementations define "reasonable") for it is to have the object be an exotic object.

There are other implementation strategies for "stack" that don't involve an exotic Error object, of course (e.g. SpiderMonkey implements it as an accessor property on Error.prototype).  They have their own tradeoffs, though.

Not returning an ordinary object from the Error constructor is
non-conformant and, assuming that conformance is a requirement for V8,
it's a bug.

Sure, just like arguably the presence of the "stack" property to start with is a bug, because per spec it's totally unexpected.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Boris Zbarsky
On 1/10/17 2:31 PM, Michał Wadas wrote:
> Implementations are allowed to extend objects. Otherwise presence of
> global/console/// would violate spec...

http://www.ecma-international.org/ecma-262/6.0/#sec-global-object 
explicitly says that the global object may have additional properties,
so global .console is clearly not a spec violation.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Michał Wadas

Actually here spec repeats itself because...

A conforming implementation of ECMAScript may provide additional types, values, objects, properties, and functions beyond those described in this specification. In particular, a conforming implementation of ECMAScript may provide properties not described in this specification, and values for those properties, for objects that are described in this specification.

So implementation is explicitly allowed to add new properties on objects.

Though, internal methods and internal slots are not properties:

Internal slots correspond to internal state that is associated with objects and used by various ECMAScript specification algorithms. Internal slots are not object properties and they are not inherited.

So it's spec violation to have custom [[GetOwnProperty]] implementation on ordinary objects.

On 10/01/17 20:36, Boris Zbarsky wrote:
On 1/10/17 2:31 PM, Michał Wadas wrote:
Implementations are allowed to extend objects. Otherwise presence of
global/console/// would violate spec...

http://www.ecma-international.org/ecma-262/6.0/#sec-global-object explicitly says that the global object may have additional properties, so global .console is clearly not a spec violation.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Isiah Meadows-2

To clarify, what engine has the bug here? I've lost that context.


On Tue, Jan 10, 2017, 14:54 Michał Wadas <[hidden email]> wrote:

Actually here spec repeats itself because...

A conforming implementation of ECMAScript may provide additional types, values, objects, properties, and functions beyond those described in this specification. In particular, a conforming implementation of ECMAScript may provide properties not described in this specification, and values for those properties, for objects that are described in this specification.

So implementation is explicitly allowed to add new properties on objects.

Though, internal methods and internal slots are not properties:

Internal slots correspond to internal state that is associated with objects and used by various ECMAScript specification algorithms. Internal slots are not object properties and they are not inherited.

So it's spec violation to have custom [[GetOwnProperty]] implementation on ordinary objects.

On 10/01/17 20:36, Boris Zbarsky wrote:
On 1/10/17 2:31 PM, Michał Wadas wrote:
Implementations are allowed to extend objects. Otherwise presence of
global/console/// would violate spec...

http://www.ecma-international.org/ecma-262/6.0/#sec-global-object explicitly says that the global object may have additional properties, so global .console is clearly not a spec violation.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Michał Wadas

V8 have bug.

Reproduction code:

Error.prepareStackTrace = ()=>{throw 123}
Object.getOwnPropertyDescriptor(new Error, 'stack') // throws 123


It should be probably filled on V8 bug tracker.

On 10/01/17 21:14, Isiah Meadows wrote:

To clarify, what engine has the bug here? I've lost that context.


On Tue, Jan 10, 2017, 14:54 Michał Wadas <[hidden email]> wrote:

Actually here spec repeats itself because...

A conforming implementation of ECMAScript may provide additional types, values, objects, properties, and functions beyond those described in this specification. In particular, a conforming implementation of ECMAScript may provide properties not described in this specification, and values for those properties, for objects that are described in this specification.

So implementation is explicitly allowed to add new properties on objects.

Though, internal methods and internal slots are not properties:

Internal slots correspond to internal state that is associated with objects and used by various ECMAScript specification algorithms. Internal slots are not object properties and they are not inherited.

So it's spec violation to have custom [[GetOwnProperty]] implementation on ordinary objects.

On 10/01/17 20:36, Boris Zbarsky wrote:
On 1/10/17 2:31 PM, Michał Wadas wrote:
Implementations are allowed to extend objects. Otherwise presence of
global/console/// would violate spec...

http://www.ecma-international.org/ecma-262/6.0/#sec-global-object explicitly says that the global object may have additional properties, so global .console is clearly not a spec violation.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Boris Zbarsky
In reply to this post by Michał Wadas
On 1/10/17 2:54 PM, Michał Wadas wrote:
> Internal slots correspond to internal state that is associated with
> objects and used by various ECMAScript specification algorithms.
> *Internal slots are not object properties* and they are not inherited.

OK, so having an internal slot for the value of .stack would be a spec
violation too, yes?

> So it's spec violation to have custom [[GetOwnProperty]] implementation
> on ordinary objects.

Sure.  Ideally such things would be brought to the committee so the spec
could be adjusted as needed for real-life (or implementations changed if
real life does not actually require the exotic behavior).  That's what's
happened in the past for things like the global object.

Really, .stack or equivalent just needs to be standardized; then this
will all get sorted out.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Isiah Meadows-2
In reply to this post by Michał Wadas
Not if it's (likely) throwing from the `new Error`.

On Tue, Jan 10, 2017, 15:16 Michał Wadas <[hidden email]> wrote:

V8 have bug.

Reproduction code:

Error.prepareStackTrace = ()=>{throw 123}
Object.getOwnPropertyDescriptor(new Error, 'stack') // throws 123


It should be probably filled on V8 bug tracker.


On 10/01/17 21:14, Isiah Meadows wrote:

To clarify, what engine has the bug here? I've lost that context.


On Tue, Jan 10, 2017, 14:54 Michał Wadas <[hidden email][hidden email]> wrote:

Actually here spec repeats itself because...

A conforming implementation of ECMAScript may provide additional types, values, objects, properties, and functions beyond those described in this specification. In particular, a conforming implementation of ECMAScript may provide properties not described in this specification, and values for those properties, for objects that are described in this specification.

So implementation is explicitly allowed to add new properties on objects.

Though, internal methods and internal slots are not properties:

Internal slots correspond to internal state that is associated with objects and used by various ECMAScript specification algorithms. Internal slots are not object properties and they are not inherited.

So it's spec violation to have custom [[GetOwnProperty]] implementation on ordinary objects.

On 10/01/17 20:36, Boris Zbarsky wrote:
On 1/10/17 2:31 PM, Michał Wadas wrote:
Implementations are allowed to extend objects. Otherwise presence of
global/console/// would violate spec...

http://www.ecma-international.org/ecma-262/6.0/#sec-global-object explicitly says that the global object may have additional properties, so global .console is clearly not a spec violation.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Boris Zbarsky
On 1/11/17 6:43 AM, Isiah Meadows wrote:
> Not if it's (likely) throwing from the `new Error`.

It's not.  The "stack" property in V8 quacks like a value property for
the most part, but the first access to it invokes some code that does
the (lazy) stack string construction.  That process involves calling
Error.prepareStackTrace if such a thing exists.

Specifically, as of today, see
https://github.com/v8/v8/blob/d5a0860e87b5f8d88432cf628f4bbc0cc922317f/src/messages.cc#L927-L954 
which is called from
https://github.com/v8/v8/blob/d5a0860e87b5f8d88432cf628f4bbc0cc922317f/src/accessors.cc#L1169

The whole setup is basically designed to have things that look like data
properties but actually involve executing code to compute the property
value (and possibly executing code when the "value" property is set).

SpiderMonkey has similar things as well, though we've been getting rid
of them as much as possible.  The obvious one that remains is .length on
Array objects.  This allows Array objects to be non-exotic for practical
purposes in terms of their engine representation, and hence not suffer
the performance penalties exotic objects suffer.  In spec terms, of
course, Array instances are just exotic objects.  In an ideal world, the
implementation detail is just that and is not observable....

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Isiah Meadows-2

Okay. The error stack being constructed that early is odd, though.


On Wed, Jan 11, 2017, 10:39 Boris Zbarsky <[hidden email]> wrote:
On 1/11/17 6:43 AM, Isiah Meadows wrote:
> Not if it's (likely) throwing from the `new Error`.

It's not.  The "stack" property in V8 quacks like a value property for
the most part, but the first access to it invokes some code that does
the (lazy) stack string construction.  That process involves calling
Error.prepareStackTrace if such a thing exists.

Specifically, as of today, see
https://github.com/v8/v8/blob/d5a0860e87b5f8d88432cf628f4bbc0cc922317f/src/messages.cc#L927-L954
which is called from
https://github.com/v8/v8/blob/d5a0860e87b5f8d88432cf628f4bbc0cc922317f/src/accessors.cc#L1169

The whole setup is basically designed to have things that look like data
properties but actually involve executing code to compute the property
value (and possibly executing code when the "value" property is set).

SpiderMonkey has similar things as well, though we've been getting rid
of them as much as possible.  The obvious one that remains is .length on
Array objects.  This allows Array objects to be non-exotic for practical
purposes in terms of their engine representation, and hence not suffer
the performance penalties exotic objects suffer.  In spec terms, of
course, Array instances are just exotic objects.  In an ideal world, the
implementation detail is just that and is not observable....

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Boris Zbarsky
On 1/11/17 3:12 PM, Isiah Meadows wrote:
> Okay. The error stack being constructed that early is odd, though.

I'm not sure I follow.  The error stack in SpiderMonkey and V8 (and
JavaScriptCore too, afaict) is captured at the point when the Error
object is created.  The captured thing is information that can be used
to construct a stack string later.

Then getting .stack constructs the stack string.  This operation is
somewhat expensive, so is deferred until someone asks.

In V8, the stringification process includes an explicit
script-modifiable hook: the "prepareStackTrace" property of the Error
constructor.

Is the odd part the stack capture during Error object construction?
Were you expecting it to only be captured at the throw point?

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Isiah Meadows-2

I was expecting the error to throw on invoking the getter. Calling `Object.getOwnPropertyDescriptor` should *never* do that (spec invariant).


On Wed, Jan 11, 2017, 15:30 Boris Zbarsky <[hidden email]> wrote:
On 1/11/17 3:12 PM, Isiah Meadows wrote:
> Okay. The error stack being constructed that early is odd, though.

I'm not sure I follow.  The error stack in SpiderMonkey and V8 (and
JavaScriptCore too, afaict) is captured at the point when the Error
object is created.  The captured thing is information that can be used
to construct a stack string later.

Then getting .stack constructs the stack string.  This operation is
somewhat expensive, so is deferred until someone asks.

In V8, the stringification process includes an explicit
script-modifiable hook: the "prepareStackTrace" property of the Error
constructor.

Is the odd part the stack capture during Error object construction?
Were you expecting it to only be captured at the throw point?

-Boris

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Jordan Harband
Per https://tc39.github.io/ecma262/#sec-object.getownpropertydescriptor , `Object.getOwnPropertyDescriptor` will throw if you pass it `null` or `undefined` as the first argument, if you pass it something as the second argument that can't be coerced to a primitive (ie, a valueOf or toString throws, or both are missing), or if the object you pass is a Proxy (or other exotic object) whose `[[GetOwnProperty]]` trap throws or returns anything other than an Object or `undefined`.

On Wed, Jan 11, 2017 at 5:55 PM, Isiah Meadows <[hidden email]> wrote:

I was expecting the error to throw on invoking the getter. Calling `Object.getOwnPropertyDescriptor` should *never* do that (spec invariant).


On Wed, Jan 11, 2017, 15:30 Boris Zbarsky <[hidden email]> wrote:
On 1/11/17 3:12 PM, Isiah Meadows wrote:
> Okay. The error stack being constructed that early is odd, though.

I'm not sure I follow.  The error stack in SpiderMonkey and V8 (and
JavaScriptCore too, afaict) is captured at the point when the Error
object is created.  The captured thing is information that can be used
to construct a stack string later.

Then getting .stack constructs the stack string.  This operation is
somewhat expensive, so is deferred until someone asks.

In V8, the stringification process includes an explicit
script-modifiable hook: the "prepareStackTrace" property of the Error
constructor.

Is the odd part the stack capture during Error object construction?
Were you expecting it to only be captured at the throw point?

-Boris

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Boris Zbarsky
In reply to this post by Isiah Meadows-2
On 1/11/17 8:55 PM, Isiah Meadows wrote:
> I was expecting the error to throw on invoking the getter. Calling
> `Object.getOwnPropertyDescriptor` should *never* do that (spec invariant).

There is no getter, from the JS point of view.  It's a value property.
That's the whole point of this conversation.

We seem to be in violent agreement that what v8 is doing is a spec
violation, fwiw.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

T.J. Crowder-2
So to sum up, then, and circle back to Francisco Tolmasky's original question:

* For ordinary objects, `Object.getOwnPropertyDescriptor` shouldn't
have side-effects because none of the ordinary operations it uses has
side effects.
* For exotic objects, it may well have side effects as a result of an
exotic version of [[GetOwnProperty]]; for instance, Adam Klein's
`Proxy` example.
* `Error` objects are specified as ordinary objects.
* V8's `Error` object has a `stack` property that claims to be a value
property (not an accessor).
* V8's `Error` object is a exotic object, it has exotic behavior for
[[GetOwnProperty]], because it triggers filling in the string for the
captured stack trace if you call it for `stack` (it has to, in order
to provide the `value` property of the descriptor, since `stack`
claims to be a value property).
* This aspect of V8's `Error` could be in-spec by making `stack` an
accessor instead (or by building the string earlier, but it's deferred
for performance reasons).

Is that a reasonable summary?

Additionally, I believe the only exotic object defined by the
specification that has a [[GetOwnProperty]] with potential side
effects is `Proxy`.

Provided that's all correct, Francisco's answer is: Per spec, you
can't rely on `Object.getOwnPropertyDescriptor` not having side
effects unless you can guarantee you're not dealing with a `Proxy`.
Per spec, you could for non-`Proxy` objects defined by the
specification, but that's not currently the case with V8 (at least).
And there's always the possibility of host objects having exotic
[[GetOwnProperty]] behavior.

-- T.J.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Isiah Meadows-2

Okay, so it's a V8 bug. Filed it here: https://bugs.chromium.org/p/v8/issues/detail?id=5834


On Thu, Jan 12, 2017, 03:03 T.J. Crowder <[hidden email]> wrote:
So to sum up, then, and circle back to Francisco Tolmasky's original question:

* For ordinary objects, `Object.getOwnPropertyDescriptor` shouldn't
have side-effects because none of the ordinary operations it uses has
side effects.
* For exotic objects, it may well have side effects as a result of an
exotic version of [[GetOwnProperty]]; for instance, Adam Klein's
`Proxy` example.
* `Error` objects are specified as ordinary objects.
* V8's `Error` object has a `stack` property that claims to be a value
property (not an accessor).
* V8's `Error` object is a exotic object, it has exotic behavior for
[[GetOwnProperty]], because it triggers filling in the string for the
captured stack trace if you call it for `stack` (it has to, in order
to provide the `value` property of the descriptor, since `stack`
claims to be a value property).
* This aspect of V8's `Error` could be in-spec by making `stack` an
accessor instead (or by building the string earlier, but it's deferred
for performance reasons).

Is that a reasonable summary?

Additionally, I believe the only exotic object defined by the
specification that has a [[GetOwnProperty]] with potential side
effects is `Proxy`.

Provided that's all correct, Francisco's answer is: Per spec, you
can't rely on `Object.getOwnPropertyDescriptor` not having side
effects unless you can guarantee you're not dealing with a `Proxy`.
Per spec, you could for non-`Proxy` objects defined by the
specification, but that's not currently the case with V8 (at least).
And there's always the possibility of host objects having exotic
[[GetOwnProperty]] behavior.

-- T.J.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Jordan Harband
The beginnings of the Error Stacks proposal is now up at https://github.com/ljharb/proposal-error-stacks

I'm presenting it this month at TC39, hoping for it to be stage 1.

As its stands, the proposal would indeed make v8's behavior noncompliant, were it to become stage 4.

On Thu, Jan 12, 2017 at 1:04 PM, Isiah Meadows <[hidden email]> wrote:

Okay, so it's a V8 bug. Filed it here: https://bugs.chromium.org/p/v8/issues/detail?id=5834


On Thu, Jan 12, 2017, 03:03 T.J. Crowder <[hidden email]> wrote:
So to sum up, then, and circle back to Francisco Tolmasky's original question:

* For ordinary objects, `Object.getOwnPropertyDescriptor` shouldn't
have side-effects because none of the ordinary operations it uses has
side effects.
* For exotic objects, it may well have side effects as a result of an
exotic version of [[GetOwnProperty]]; for instance, Adam Klein's
`Proxy` example.
* `Error` objects are specified as ordinary objects.
* V8's `Error` object has a `stack` property that claims to be a value
property (not an accessor).
* V8's `Error` object is a exotic object, it has exotic behavior for
[[GetOwnProperty]], because it triggers filling in the string for the
captured stack trace if you call it for `stack` (it has to, in order
to provide the `value` property of the descriptor, since `stack`
claims to be a value property).
* This aspect of V8's `Error` could be in-spec by making `stack` an
accessor instead (or by building the string earlier, but it's deferred
for performance reasons).

Is that a reasonable summary?

Additionally, I believe the only exotic object defined by the
specification that has a [[GetOwnProperty]] with potential side
effects is `Proxy`.

Provided that's all correct, Francisco's answer is: Per spec, you
can't rely on `Object.getOwnPropertyDescriptor` not having side
effects unless you can guarantee you're not dealing with a `Proxy`.
Per spec, you could for non-`Proxy` objects defined by the
specification, but that's not currently the case with V8 (at least).
And there's always the possibility of host objects having exotic
[[GetOwnProperty]] behavior.

-- T.J.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Isiah Meadows-2

It still seems useful. My only nit is shouldn't they be static methods of `Error`, not `System`? (They only deal with an error-specific internal property, so it seems odd to put it in the generic system stuff.)


On Thu, Jan 19, 2017, 02:34 Jordan Harband <[hidden email]> wrote:
The beginnings of the Error Stacks proposal is now up at https://github.com/ljharb/proposal-error-stacks

I'm presenting it this month at TC39, hoping for it to be stage 1.

As its stands, the proposal would indeed make v8's behavior noncompliant, were it to become stage 4.

On Thu, Jan 12, 2017 at 1:04 PM, Isiah Meadows <[hidden email]> wrote:

Okay, so it's a V8 bug. Filed it here: https://bugs.chromium.org/p/v8/issues/detail?id=5834


On Thu, Jan 12, 2017, 03:03 T.J. Crowder <[hidden email]> wrote:
So to sum up, then, and circle back to Francisco Tolmasky's original question:

* For ordinary objects, `Object.getOwnPropertyDescriptor` shouldn't
have side-effects because none of the ordinary operations it uses has
side effects.
* For exotic objects, it may well have side effects as a result of an
exotic version of [[GetOwnProperty]]; for instance, Adam Klein's
`Proxy` example.
* `Error` objects are specified as ordinary objects.
* V8's `Error` object has a `stack` property that claims to be a value
property (not an accessor).
* V8's `Error` object is a exotic object, it has exotic behavior for
[[GetOwnProperty]], because it triggers filling in the string for the
captured stack trace if you call it for `stack` (it has to, in order
to provide the `value` property of the descriptor, since `stack`
claims to be a value property).
* This aspect of V8's `Error` could be in-spec by making `stack` an
accessor instead (or by building the string earlier, but it's deferred
for performance reasons).

Is that a reasonable summary?

Additionally, I believe the only exotic object defined by the
specification that has a [[GetOwnProperty]] with potential side
effects is `Proxy`.

Provided that's all correct, Francisco's answer is: Per spec, you
can't rely on `Object.getOwnPropertyDescriptor` not having side
effects unless you can guarantee you're not dealing with a `Proxy`.
Per spec, you could for non-`Proxy` objects defined by the
specification, but that's not currently the case with V8 (at least).
And there's always the possibility of host objects having exotic
[[GetOwnProperty]] behavior.

-- T.J.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: getOwnPropertyDescriptor side effects

Boris Zbarsky
In reply to this post by Jordan Harband
On 1/19/17 2:33 AM, Jordan Harband wrote:
> The beginnings of the Error Stacks proposal is now up
> at https://github.com/ljharb/proposal-error-stacks

I can't speak for other browsers, but the description of the Firefox
behavior in that proposal does not look correct.

Here's what I understand the Firefox behavior to be:

1)  The getter does NOT throw on a non-Error receiver.  Doing that
     would be very much not web-compatible.
2)  The behavior of the getter is as follows:

   a) If the receiver is not an object, throw.
   b) Walk up the prototype chain (note: this can invoke proxy
      [[GetPrototype]] traps) until we find either an Error object
      or Error.prototype.  If we reach null before doing either of
      those, throw.
   c) Return the stack string for the object we found.  For
      Error.prototype this would be the empty string; for an Error
      object it's the stack captured when it was created.

3)  The setter doesn't care what the receiver is, as long as it's
     an object.  Again, throwing for non-Error would not be
     web-compatible.
4)  The actual behavior of the setter is to throw if called with
     no arguments.  Otherwise, the setter invokes its receiver's
     [[DefineOwnProperty]] with the property name "stack" and a
     property descriptor that looks like this:

     { [[Value]]: setterArg, [[Configurable]]: true,
       [[Writable]]: true, [[Enumerable]]: true }

     where setterArg is the first argument that was passed to the
     setter.

I should note, per items 1 and 3 above, that the proposal at
https://ljharb.github.io/proposal-error-stacks/ as of today is in fact
not web-compatible.

-Boris

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12