Enumerability of methods, getters, and setters

[tlively]

Normal methods, getters, and setters on JS classes are not enumerable, but it might be important for getters and setters to be enumerable to emulate normal own-properties. We could easily support this by using a bit in the method-kind specifier to say whether the property should be enumerable or not.

Does this sound useful?

[sjrd]

I don't think this is very useful. Enumerating all properties in the prototype chain is considered an anti pattern in JS. If you're going to enumerate the properties of an object, the recommended way is to take only the own properties. That's because you don't want the annoying enumerable methods of Object. So typical JS code would miss the getters and setters on the prototype anyway.

[guybedford]

@sjrd the problem is cases like JSON.stringify(obj) where it might be useful to have getters/setter "emulate" fields to permit idiomatic JS usage.

Edit - I suppose regardless not having [[OwnPropertyKeys]] containing the list of fields would still inhibit these kind of uses.

[guybedford]

Thinking about this some more in light of my previous comment - more useful than controlling the enumerability of prototype getters and setters would be being able to control the JS internal methods like [[OwnPropertyKeys]] and [[GetOwnProperties]] on the actual instances (not the prototypes) see https://tc39.es/ecma262/#table-essential-internal-methods. I don't see why these representations couldn't be configurable in a similar vein though.

[tlively]

The nice thing about configuring prototypes is that it Just Works on the JS side. Doing some sort of Proxy-like thing where we override the internal JS methods of Wasm objects would be much more invasive.

[guybedford]

Agreed, and I'm not saying it's desirable - rather just that it's possible, and likely more in line with the kind of solution required to solve the motivating concern raised here, because normal own properties in JavaScript exist on the instance and not the prototype. Unless I'm missing a use case here.