In addition to what Jason just posted about [[OwnPropertyKeys]], I think there are some avoidable inconsistencies in how the various object properties reflection methods are specified. As specified or proposed right now, we have three different such functions: Object.keys, Object.getOwnPropertyNames, and Reflect.ownKeys. Here's their respective behavior:
Object.keys: returns an array of keys of all the iterable own string-keyed properties of the given object Object.getOwnPropertyNames: returns an array of keys of all the own string-keyed properties of the given object Reflect.ownKeys: returns an iterator over all the keys of own string- or symbol-keyed properties of the given object I.e., Reflect.ownKeys behaves more like Object.getOwnPropertyNames, except that it returns an iterator, and returns symbols, too. Under Jason's proposal, it'd at least not return an iterator. While I see that it's a migration hazard for Object.keys and Object.getOwnPropertyNames to return symbols, too, I think the long-term hazard introduced by the subtle differences between these three methods is of greater concern. There's just no way to tell from their names what the precise behavior will be, and the differences are subtle enough that they'll be hard to remember. For proxies, it's hard to tell which trap has to be implemented to affect the behavior of any one of these methods. Hence, I think Object.keys and Object.getOwnPropertyNames should return symbols, too. Proxies wouln't need to get a new trap at all. The migration hazard should actually be somewhat mitigated by the fact that many use cases should continue to just work in the face of symbols, while many others should fail fairly obviously. Since I don't have data to base this on, I want to reiterate that the long-term hazard of having three irritatingly similar but different methods is the real argument I'm making.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
