Reflect.getOwnPropertySymbols?
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 harmony:reflect_api)
In ES6, the primary role of the Reflect object is to provide direct access to an object's essential internal methods: 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:
- Is there any benefit to duplicating to having the same function that exists on both Object.* and Reflect.*
- If a new derived reflective operation is added, should it go on Object.* or Reflect.*
On Mon, Mar 16, 2015 at 11:53 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
In ES6, the primary role of the Reflect object is to provide direct access to an object's essential internal methods: people.mozilla.org/~jorendorff/es6-draft.html#sec-object-internal-methods-and-internal-slots
To further elaborate on this: one way this is useful is that the 14 essential internal methods are exactly the operations you can trap with a custom Proxy. It's useful, when writing a Proxy, to use the Reflect methods as fallbacks:
var alertingProxy = new Proxy(obj, {
// Proxy: hook into property assignment
set(t, key, value, receiver) {
alert(`setting the ${key} property of ${t} to ${value}`);
// Reflect: do normal property assignment
return Reflect.set(t, key, value, receiver);
}
});Thanks Allen and Jason! This completely cleared it all up for me!
2015-03-16 17:53 GMT+01:00 Allen Wirfs-Brock <allen at wirfs-brock.com>:
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:
- Is there any benefit to duplicating to having the same function that exists on both Object.* and Reflect.*
Note that not all methods we defined on Reflect.* were mere duplicates of their Object.* counterparts. Some had different return values. For instance, Object.freeze(obj) always returns obj or throws, while Reflect.freeze(obj) was specced to return a simple boolean value indicating success or failure.
That said, I think we made the right call to limit Reflect.* to just the essential internal methods in ES6.
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
(From harmony:reflect_api)
But ES6 adds [Object.getOwnPropertySymbols][1], but has no Reflect api to match. Is this a mistake or intentional?
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.
1: people.mozilla.org/~jorendorff/es6-draft.html#sec-object.getownpropertysymbols