Normative: Remove [[Enumerate]] and associated reflective capabilities

[bterlson]

Summary of changes (actually quite simple so I expect I'm missing something major :-P)

• 6.1.7.2 Removed [[Enumerate]] from the table and list of invariants
• 9.5 Proxy Object Internal Methods and Interal Slots, [[Enumerate]] table entry removed.
• 9.4.6.1.1 Module Namespace Object [[Enumerate]] deleted
• 9.5.11 Proxy [[Enumerate]] deleted
• Moved ordinary [[Enumerate]] section to end of 13.7.5 for-in, renamed to EnumerateObjectProperties.
  • Add an assert to step 1 to signal callers we expect they'll only pass objects
  • Updated informative definition of EnumerateObjectProperties
• 13.7.5.12 for-in head evaluation calls EnumerateObjectProperties(obj) instead of obj.[[Enumerate]]
• EnumerableOwnNames: the names are always ordered the same as EnumerateObjectProperties (since we don't have to worry about this not being enforceable with proxies anymore)
• 26.1.5 Reflect.enumerate deleted
• 26.3.2 module namespace object's [ @@iterator ] calls EnumerateObjectProperties instead of [[Enumerate]]

[allenwb]

Re 26.3.2. I'd just take the guts of 9.4.6.11 and insert them into 26.3.2. There is no need to tie namespace name iteration to for-in semantics

[bterlson]

@allenwb I thought about that but I'd have to call for-in if the method were applied to a non-module namespace object. This was simpler I thought, but happy to change it to something like:

1. Let N be the this value.
2. If N is a Module Namespace exotic object, then
   1. Let exports be the value of N's [[Exports]] internal slot.
   2. Return ! CreateListIterator(N).
3. Else if Type(N) is Object, return ? EnumerateObjectProperties(N);
4. Else, N is not an Object, throw a TypeError exception.

[allenwb]

??? 26.3.2 is specifically an iterator over the names of a module name space object. It really wasn't intended to be any sort of general own property name iterator. It is just sort of a design fluke it ended up that way.

I think it would be better for it to just throw if it is applied to something that isn't a module namespace exotic object

[bterlson]

Uhh, yes, that is much better. Updating the PR.

[bterlson]

Fixed, thanks @allenwb.

[ljharb]

Is the note on the next line ("<p>The order of elements in the returned list is the same as the enumeration order that is used by a for-in statement.</p>" but github has trouble showing it and won't let me comment on it) still necessary? It seems implied by EnumerateObjectProperties.

[bterlson]

Agreed, removed the note.

[annevk]

How does HTML make what is now [[Enumerate]] return CreateListIterator(« ») for WindowProxy and Location objects when they are accessed from a different origin? It seems there would no longer be a hook to do that.

[domenic]

@annevk probably the best way is to make GOPD always return enumerable: false. Combined with GetPrototypeOf returning null, that should do the trick.

[anba]

Do you think it makes sense to define that the return method of the iterator object is null? This should ensure that the iterator object cannot escape to user code when a break or return statement is nested in the for-in loop.

[bterlson]

Yeah, I guess both throw and return should be null.

[bterlson]

And actually the requirement that it MUST inherit from %IteratorPrototype% is kind of bogus since the intention is this isn't observable. Can I simply remove that line?

[anba]

Yes, you can remove that line. I'd probably also add the note "The Iterator object is never directly accessible to ECMAScript code." to underline that implementations don't actually need to create a JavaScript object.

[allenwb]

except that I think you should have an "as if" in "... of prototype objects must be obtained by invoking EnumerateObjectProperties...".

It should probably "... of prototype objects must be obtained as if by performing ..."

We want to required the MOP operation calls, but should suggest that creation of intermediate iterators are required.

[bterlson]

We want to required the MOP operation calls, but should suggest that creation of intermediate iterators are required.

I think you mean NOT required? I think the note in EnumerateObjectProperties that says that the iterator is never exposed to ECMAScript code makes that clear. But I can add back the first "as if by" if it helps.

[broofa]

My apologies if this isn't appropriate here, but I'm not finding answers elsewhere on the web. With Proxy#enumerate no longer available, how does one define the enumerable properties of a proxy object?

Specifically, I have a case where I have a Proxy object that stores values on an internal Object. It'd be nice if console.log(proxyObject) showed the values in question, rather than just "{}" (empty object), but it's not clear there's a way to do that. :-/

[ljharb]

@broofa you can use the ownKeys proxy trap for that.

[broofa]

@ljharb Hmm... that's not what I'm seeing. Am I doing something wrong, or are Node et al misinterpreting the spec?

> x = new Proxy({}, {ownKeys() {return ['a', 'b', 'c']}, get() {return 'foo'}, has() {return true}})
{}
> 'a' in x
true
> for (k in x) console.log(k)
undefined
> console.log(x)
{}
undefined
> Object.keys(x)
[]

[ljharb]

I believe you also need to define a getOwnPropertyDescriptor trap.

[broofa]

@ljharb Thanks, that works!

I'm leaving a breadcrumb here for what I ended up with in case anyone else stumbles across this, and also because of a possible(?) spec issue described below. If this is getting spammy, my apologies, and let me know where I should move this conversation to.

So, example of adding a virtual "c" property to a proxy object:

> x = new Proxy({a: 1, b:2}, {
...   get(o, k) {return k == `c` ? o.a + o.b : o[k];},
...   ownKeys(o) {return [...Object.keys(o), 'c']},
...   getOwnPropertyDescriptor(o, k) {return {configurable: true, enumerable: true, value: this.get(o, k)}},
... })
{ a: 1, b: 2, c: 3 }

BTW, it's worth noting that I had to set the descriptor value: this.get(o, k) to work around an inconvenient problem: Defining property descriptors means proxy properties are now defined independently in two places: handler.get(), and propertyDescriptor.value. Without a descriptor value the values can be either defined or undefined depending on how they're referenced. For example, with no descriptor value in Node ...

> x = new Proxy({a: 1, b:2}, {
...   get(o, k) {return k == `c` ? o.a + o.b : o[k];},
...   ownKeys(o) {return [...Object.keys(o), 'c']},
...   getOwnPropertyDescriptor(o, k) {return {configurable: true, enumerable: true}},
... })
Proxy [ { a: 1, b: 2 },
  { getOwnPropertyDescriptor: [Function: getOwnPropertyDescriptor],
    ownKeys: [Function: ownKeys],
    get: [Function: get] } ]
> console.log(x)
{ a: undefined, b: undefined, c: undefined }
undefined
> x.a
1
> x.b
2
> x.c
3
>

I was going to report this as a bug against node's util.inspect() method, but I'm not convinced the current behavior is wrong. If you Object.defineProperty() a value on a vanilla Object (i.e. outside a proxy), the property descriptor value is the canonical value for that object. Preferring the property descriptor value over the proxy's handler.get() value is arguably correct... or at least consistent with normal Object property descriptor behavior.

Does the Proxy spec address how implementors are expected to resolve this apparent inconsistency? FWIW, Safari and Firefox appear to use handler.get() if the descriptor value is omitted, which is kind of nice.

[claudepache]

@broofa

BTW, it's worth noting that I had to set the descriptor value: this.get(o, k) to work around an inconvenient problem: Defining property descriptors means proxy properties are now defined independently in two places: handler.get(), and propertyDescriptor.value.

The [[OwnPropertyKeys]], [[GetOwnProperty]], [[Get]] and [[HasProperty]] internal methods of the object give partially redundant informations, and it is the responsibility of the writer of the Proxy handler to keep them reasonably consistent by implementing carefully, or not implementing, the corresponding traps (ownKeys, getOwnPropertyDescriptor, get and has). BTW, this is an argument for not having [[Enumerate]], because it would be one more internal method to keep consistent with others.

Does the Proxy spec address how implementors are expected to resolve this apparent inconsistency? FWIW, Safari and Firefox appear to use handler.get() if the descriptor value is omitted, which is kind of nice.

ECMAScript does not specify the behaviour of debugging facilities such as console.log or util.inspect.

[broofa]

ECMAScript does not specify the behaviour of debugging facilities such as console.log or util.inspect.

My point was only mainly that, in making an object enumerable, you are forced to confront this ambiguity about where values are defined. That the behavior of calling code (e.g. util.inspect) is not well defined just highlights this ambiguity.

[allenwb]

Preferring the property descriptor value over the proxy's handler.get() value is arguably correct... or at least consistent with normal Object property descriptor behavior.

Does the Proxy spec address how implementors are expected to resolve this apparent inconsistency?

The MOP (ie Proxy) spec. allows an exotic object to produce all sorts of inconsistent results.
The only consistency requirements are those defined as essential invariants.