Re: getOwnPropertyDescriptor side effects

On 1/21/17 1:14 AM, Jordan Harband wrote: In that case I would be delighted if you filed this as an issue on the repo. I would be delighted to do it, if it had not been filed back in November, including the comments about how your description of the Firefox behavior doesn't match the actual

Re: getOwnPropertyDescriptor side effects

In that case I would be delighted if you filed this as an issue on the repo. On Fri, Jan 20, 2017 at 4:03 PM, Boris Zbarsky wrote: > On 1/20/17 2:26 PM, Jordan Harband wrote: > >> Also note that for changing existing behavior to be "web incompatible", >> all the browsers have

Re: getOwnPropertyDescriptor side effects

On 1/20/17 2:26 PM, Jordan Harband wrote: Also note that for changing existing behavior to be "web incompatible", all the browsers have to *agree* on it That may or may not be true. But in any case, this proposal specifies behavior that disagrees with all browsers, who agree with each other.

Re: getOwnPropertyDescriptor side effects

If you have feedback on the proposal, please file issues on the repo instead of replying in the thread. Also note that for changing existing behavior to be "web incompatible", all the browsers have to *agree* on it - in other words, if you're currently relying on behavior that only works in some

Re: getOwnPropertyDescriptor side effects

On Thu, Jan 19, 2017 at 10:52 AM, Mark S. Miller wrote: > > > On Thu, Jan 19, 2017 at 9:30 AM, Boris Zbarsky wrote: > >> On 1/19/17 12:24 PM, Isiah Meadows wrote: >> >>> 1. What does Firefox do with the getter on non-errors? >>> >> >> Oh, I didn't make that

Re: getOwnPropertyDescriptor side effects

On Thu, Jan 19, 2017 at 9:30 AM, Boris Zbarsky wrote: > On 1/19/17 12:24 PM, Isiah Meadows wrote: > >> 1. What does Firefox do with the getter on non-errors? >> > > Oh, I didn't make that clear, did I? On a non-error in the getter, we > have an Error object or Error.prototype

Re: getOwnPropertyDescriptor side effects

Thanks! I see now. On Thu, Jan 19, 2017, 12:30 Boris Zbarsky wrote: > On 1/19/17 12:24 PM, Isiah Meadows wrote: > > 1. What does Firefox do with the getter on non-errors? > > Oh, I didn't make that clear, did I? On a non-error in the getter, we > have an Error object or

Re: getOwnPropertyDescriptor side effects

On 1/19/17 12:24 PM, Isiah Meadows wrote: 1. What does Firefox do with the getter on non-errors? Oh, I didn't make that clear, did I? On a non-error in the getter, we have an Error object or Error.prototype (which appeared somewhere on our receiver's proto chain). Those objects all have,

Re: getOwnPropertyDescriptor side effects

I agree that no setter (I didn't see one in the spec) is not Web compatible. In fact, I recall Bluebird running into serious issues with erroneous warnings over read-only stacks in PhantomJS, and had to disable them in my tests as a result. (I eventually dropped the dependency in favor of native

Re: getOwnPropertyDescriptor side effects

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

Re: getOwnPropertyDescriptor side effects

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 wrote: > The beginnings

Re: getOwnPropertyDescriptor side effects

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

Re: getOwnPropertyDescriptor side effects

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 wrote: > So to sum up, then, and circle back to Francisco Tolmasky's original > question: > > * For ordinary objects,

Re: getOwnPropertyDescriptor side effects

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

Re: getOwnPropertyDescriptor side effects

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

Re: getOwnPropertyDescriptor side effects

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,

Re: getOwnPropertyDescriptor side effects

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 wrote: > On 1/11/17 3:12 PM, Isiah Meadows wrote: > > Okay. The error stack being constructed

Re: getOwnPropertyDescriptor side effects

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

Re: getOwnPropertyDescriptor side effects

Okay. The error stack being constructed that early is odd, though. On Wed, Jan 11, 2017, 10:39 Boris Zbarsky 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

Re: getOwnPropertyDescriptor side effects

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

Re: getOwnPropertyDescriptor side effects

Really, the only thing that matters is in fact *observable* behavior, so I'd concur. I just get the feeling several people in this thread don't quite understand that part of the spec, or in a few cases, the spec itself and its invariants. On Wed, Jan 11, 2017, 04:17 Raul-Sebastian Mihăilă

Re: getOwnPropertyDescriptor side effects

Not if it's (likely) throwing from the `new Error`. On Tue, Jan 10, 2017, 15:16 Michał Wadas wrote: > V8 have bug. > > Reproduction code: > Error.prepareStackTrace = ()=>{throw 123} > Object.getOwnPropertyDescriptor(new Error, 'stack') // throws 123 > > It should be

Re: getOwnPropertyDescriptor side effects

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

Re: getOwnPropertyDescriptor side effects

> On Jan 10, 2017, at 9:57 AM, Boris Zbarsky wrote: > > On 1/10/17 1:56 AM, Raul-Sebastian Mihăilă wrote: >> Even if the `stack` property is non-standard, getting its property >> descriptor must follow the same general rules for ordinary objects. > > Not if its (non-standard)

Re: getOwnPropertyDescriptor side effects

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

Re: getOwnPropertyDescriptor side effects

To clarify, what engine has the bug here? I've lost that context. On Tue, Jan 10, 2017, 14:54 Michał Wadas wrote: > Actually here spec repeats itself because... > > *A conforming implementation of ECMAScript may provide additional* types, > values, objects, *properties*,

Re: getOwnPropertyDescriptor side effects

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

Re: getOwnPropertyDescriptor side effects

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

Re: getOwnPropertyDescriptor side effects

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

getOwnPropertyDescriptor side effects

I disagree regarding the conformance. According to the conformance section ( https://tc39.github.io/ecma262/#sec-conformance): A conforming implementation of ECMAScript may provide additional types, values, objects, properties, and functions beyond those described in this specification. In

Re: getOwnPropertyDescriptor side effects

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

getOwnPropertyDescriptor side effects

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. https://tc39.github.io/ecma262/#sec-ordinarycreatefromconstructor

Re: getOwnPropertyDescriptor side effects

On 1/10/17 1:56 AM, Raul-Sebastian Mihăilă wrote: Even if the `stack` property is non-standard, getting its property descriptor must follow the same general rules for ordinary objects. Not if its (non-standard) implementation makes the object itself non-ordinary (again, non-standard)...

Re: getOwnPropertyDescriptor side effects

Even if the `stack` property is non-standard, getting its property descriptor must follow the same general rules for ordinary objects. On Tue, Jan 10, 2017 at 2:25 AM, Isiah Meadows wrote: > First, the `stack` property is non-standard. Second, proxies don't have to > be

Re: getOwnPropertyDescriptor side effects

First, the `stack` property is non-standard. Second, proxies don't have to be stateful, and many of them aren't. On Fri, Jan 6, 2017, 14:58 Raul-Sebastian Mihăilă wrote: > That sounds like a bug because error objects are ordinary objects and the > [[GetOwnProperty]]

getOwnPropertyDescriptor side effects

That sounds like a bug because error objects are ordinary objects and the [[GetOwnProperty]] internal method of ordinary objects doesn't have side effects. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

With the advent of Proxy in ES2015, getOwnPropertyDescriptor can always have side-effects: Object.getOwnPropertyDescriptor(new Proxy({}, { getOwnPropertyDescriptor() { throw "hello world" } }), "foo") On Fri, Jan 6, 2017 at 11:11 AM, Francisco Tolmasky wrote: > Is there any

getOwnPropertyDescriptor side effects

Is there any position on whether getOwnPropertyDescriptor should not have side-effects? I ask because some v8 getOwnPropertyDescriptor *do* have side effects (for example, Object.getOwnPropertyDescriptor(new Error, “stack”) will call Error.prepareStackTrace (it used to not)). Currently I treat