Reflect.getOwnPropertySymbols?

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Mar 16 16:53:20 UTC 2015


On Mar 15, 2015, at 2:48 PM, Keith Cirkel wrote:

> It seems like the intention of the Reflect API was to create a standard object were all reflection operations could reside.
> 
> Now that we have modules, a “@reflect” module is a more natural place for many of the reflection methods previously defined on Object. For backwards-compatibility purposes, it is unlikely that the static methods on Object will disappear. However, new methods should likely be added to the “@reflect” module rather than to the Object constructor.
> 
> (From http://wiki.ecmascript.org/doku.php?id=harmony:reflect_api) 

In ES6, the primary role of the Reflect object is to provide direct access to an object's essential internal methods: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-internal-methods-and-internal-slots 

Most of the Object.* methods are defined in terms of the internal  methods but they also typically augment the internal method behavior in some way.

> 
> But ES6 adds [Object.getOwnPropertySymbols][1], but has no Reflect api to match. Is this a mistake or intentional?

Intentional. Neither Object.getOwnPropertyNames nor Object.getOwnPropertySymbols directly correspond to one of the essential internal methods. Instead, both are defined as applying filters to the results of the [[OwnPropertyKeys]] essential internal method (which ES code can directly invoke via Reflect.ownKeys)

> 
> On the same subject - the original Reflect proposal seemed to add the complete set of Object statics, including .freeze/isFrozen, .seal/isSealed, which seem to be missing from the RC. Once again, is this intentional? My google-fu seems to be lacking wrt finding anything about dropping these.

Again, those Object.* functions aren't actually  primitive but instead defined in terms of the essential internal methods.

In ES6, Reflect.* only has properties corresponding to the essential internal methods.

It's possible, that in the future "derived" reflective operations such as those might be added to Reflect.*.

There are a couple of design questions to consider for future extensions:

1) Is there any benefit to duplicating to having the same function that exists on both Object.* and Reflect.*
2) If a new derived reflective operation is added, should it go on Object.* or Reflect.*


Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150316/df7167be/attachment-0001.html>


More information about the es-discuss mailing list