Per May 2016 TC39 consensus, Object.getOwnPropertyDescriptors is now stage 4!

[ljharb]

(tc39/proposal-object-getownpropertydescriptors#9)

[claudepache]

Should we run this step also when descriptor is undefined? (Could happen if obj is a proxy, for instance.)

[ljharb]

I think that's perfectly fine. If a Proxy chooses to expose that it is a Proxy by providing a key in [[OwnPropertyKeys]] that does not have a corresponding descriptor in [[GetOwnProperty]], I think that intentional information leak should be propagated.

[WebReflection]

what happens if you Object.getOwnpropertyDescriptor(proxy, key) and/or
Reflect.ownKeys(proxyObject) ?

On Wed, May 25, 2016 at 3:24 PM, Claude Pache notifications@github.com
wrote:

In spec.html
#582 (comment):

@@ -22683,6 +22683,21 @@

•  <emu-clause id="sec-object.getownpropertydescriptors">
  

•    <h1>Object.getOwnPropertyDescriptors ( _O_ )</h1>
  

•    <p>When the `getOwnPropertyDescriptors` function is called, the following steps are taken:</p>
  

•    <emu-alg>
  

•      1. Let _obj_ be ? ToObject(_O_).
  

•      1. Let _ownKeys_ be ? _obj_.[[OwnPropertyKeys]]().
  

•      1. Let _descriptors_ be ! ObjectCreate(%ObjectPrototype%).
  

•      1. Repeat, for each element _key_ of _ownKeys_ in List order,
  

•        1. Let _desc_ be ? _obj_.[[GetOwnProperty]](_key_).
  

•        1. Let _descriptor_ be ! FromPropertyDescriptor(_desc_).
  

•        1. Perform ! CreateDataProperty(_descriptors_, _key_, _descriptor_).
  

Should we run this step also when descriptor is undefined? (Could
happen if obj is a proxy, for instance.)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/tc39/ecma262/pull/582/files/55ac18633a0e68ba24b1f62288e3c77ddece58bd#r64581739

[ljharb]

Reflect.ownKeys should return the same as [[OwnPropertyKeys]], and Object.getOwnPropertyDescriptor I believe will call [[GetOwnProperty]], so I think you'd get undefined for a key from a Proxy that had this inconsistent behavior.

[claudepache]

If Object.defineProperties accepts undefined in place of a property descriptor, it is probably fine for Object.getOwnPropertyDescriptors to produce undefined in place of a property descriptor, so that the following code will work:

Object.defineProperties(obj2, Object.getOwnPropertyDescriptors(obj1))

I’ve checked that Object.defineProperties does indeed accept undefined in place of a descriptor since ES6 (see step 5b), but the browsers still do not. (And test262 apparently forgot to be updated.)

[domenic]

I guess my similarly-weak preference is that it should just pass through what the MOP gives it and not be responsible for normalizing or censoring.

[ljharb]

My weak preference is the same as @domenic's - also, this same "issue" already exists with

const obj = {};
Reflect.ownKeys(badProxy).forEach(x => {
  Object.defineProperty(obj, x, Reflect.getOwnPropertyDescriptor(badProxy, x));
});

[bterlson]

I don't see this as normalizing or censoring. To me, if GetOwnProperty returns undefined, the property doesn't exist. The fact that previously OwnKeys said the property was there is of no consequence - maybe it doesn't exist now because the proxy is confused, or maybe there were side effects that removed it.

[domenic]

I don't see this as normalizing or censoring. To me, if GetOwnProperty returns undefined, the property doesn't exist.

I guess this is the core of our disagreement: if GetOwnProperty returns undefined, that to me means that its property descriptor is undefined. That can be true if the property doesn't exist, but it can also be true if the proxy wants to return undefined and the property does exist.

Basically, "what does it mean to exist"? :)

[bterlson]

There is no such thing as a property with an undefined property descriptor. Proxies may change their answers about whether a property exists, but if a property exists, it has a property descriptor.

[bterlson]

So I've been pushed to a stronger opinion that the only conceptual model that makes sense is that a property for which GetOwnProperty returns undefined does not exist in any sense, and that O.gOPDs should not include either non-existent properties (regardless of whether it is missing because of a confused proxy or other side effects) or invalid descriptors (viz. undefined).

I think this is an issue that is worth discussing in committee, though, so I will accept this PR as-is per May committee consensus and @ljharb will make a needs-consensus PR to fix this bug/feature.

[leobalter]

👍 @bterlson.

I believe we can solve it with a If step after desc to check it's not undefined.

I agree with @ljharb and @domenic as this looks a normalization, I also believe it solves at least reusability with broken Proxies. This is also a very specific case.

Even though, it doesn't hurt anyone applying this update after a new consensus. I won't object if @ljharb does it.

[allenwb]

I don't see how this feature can be at stage 4 when issues like this are still unsettled. Stage 4 means the spec. is complete and final.

[ljharb]

As with many of the things that have needed erratum, this can be considered a spec bug.

[bterlson]

@allenwb we made a mistake and didn't realize this issue until @claudepache brought it up. We could say that the consensus was given in error and move it back to stage 3, but I thought it would be fine to do a needs-consensus PR as a follow-up (see #593). Would you prefer the former?

[ljharb]

It's also worth noting that in the May meeting, I suggested the possibility of it being acceptable for a proposal to move backwards in stages as necessary, and that possibility was loudly and unanimously rejected.

[allenwb]

Makes me wonder about what sort of review it went through before being present to the committee for stage 4.

Stage 4 should mean that the spec. is done and can be safely implemented in production. If we know that it is i not complete and must be revised (and in particular if there is not yet committee consensus on the modified semantics) then it don't meet the stage 4 criteria, even if the committee had previous said it did.

What hard is there in leaving it at stage 3 until this is all resolved.

[bterlson]

There is no leaving it at stage 3. It got stage 4 at the last meeting.

[bterlson]

Submitted too soon... I am not opposed to saying that if we find bugs like this it goes back to stage 3. It's never been done before so I thought I'd use the existing processes (namely, needs-consensus PR). Probably a good agenda item for the next meeting :-P

[leobalter]

Stage 4 should mean that the spec. is done and can be safely implemented in production.

Agreed but I believe this proposal meets the criteria as presented in this PR. The follow-up PR has an improvement that makes the method more useful.

[bterlson]

Yeah that's a good point too. I think it's a bug (probably @allenwb does too), but the champion and others have been arguing that it's working as intended :-P