Direct proxies update

David Bruant bruant.d at
Thu Nov 24 06:45:58 PST 2011

Le 24/11/2011 10:36, Tom Van Cutsem a écrit :
> Hi,
> As a follow-up to last week's TC39 meeting, I rearranged things on the
> wiki to reflect our current thinking on proxies. The previous Proxy
> API is now superseded by the direct proxies API
> <>.
"var proxy = Proxy(target, handler);
It is not necessary to use |new| to create new proxy objects."
Just to be sure, it means that both "Proxy(target, handler)" and "new
Proxy(target, handler)" produce the same result like Array for instance ?

freeze/seal/preventExtensions: For this particular case, I do not want
to capture which function was called, but rather the intention of the
programmer to set [[Extensible]] to false. If the proxy API does not
provide a unique trap this particular operation, I have no way to create
this unique trap myself. This can be annoying if another built-in sets
[[Extensible]] to false. Even if my handler is a proxy, I can't know if
the new trap is going to set [[Extensible]] to false.

enumerate/keys/getOwnPropertyNames: It could be an idea to merge these
as well (maybe not enumerate which traverses the prototype?) into one
trap with an argument.
Or maybe 2 traps: one dedicated to enumeration of own properties, one
for proto-climbing properties.

I think a mention should be made of for-of loops
in the proxy strawman just to keep it in mind (and the reflect API?)
Also, on the iterator page, the iterate trap should rather default to
the [[iterate]] internal of the target object instead of the enumerate
trap of the proxy.

"Non-interceptable operations"
=> I think that some are lacking:
1) (which reads the [[Class]])
2) "" + proxy (which reads the [[DefaultValue]](string))
3) (all operations which include a call to ToPrimitive)

> I put my own notes on the discussion of direct proxies at the meeting
> on the old strawman page:
> <>.
> Work in progress:
> - Definition of a built-in handler that enables proxy handlers to
> still inherit all derived trap implementations, as suggested at the
> meeting:
> <>
In the non-normative implementation, there is no import of the @reflect
module (but it's used).
Though the implementation is non-normative, i'd like to provide some
feedback on it:
* "has" default derived trap:
=> I think the last line should be Reflect.has(proto, name)

* "enumerate" default derived trap: " // FIXME: filter duplicates from
=> I have seen discussed additions to Math, String.prototype, Number,
but not about Array.prototype. In a thread, Dmitry suggested an
Array.prototype.unique method. This one could be handy here. For the
non-native implementation but also for native implementations as well.
For inherited properties, why not calling Reflect.enumerate(proto) ?

> - Definition of a standard "@reflect"
> module: <>
> One observation I made while working on this module is that it's
> probably a bad idea to use keywords as trap names (delete, new), since
> such names cannot be straightforwardly imported/exported from modules.
How so?

> We should probably consider using the names 'deleteProperty' and
> 'construct' instead.
If that's really the case, I would prefer changing identifiers that can
be imported/exported from modules rather than changing names of the
Reflect API.

Once again, great work :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list