Direct proxies update
Tom Van Cutsem
tomvc.be at gmail.com
Thu Nov 24 13:11:41 PST 2011
2011/11/24 David Bruant <bruant.d at gmail.com>
> "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.
Not sure what you're after here. During the meeting, we reverted from
protect(op) to splitting back into three traps as that allows freeze and
seal to be turned into derived traps (in the virtual handler API). Also,
AFAICT there is no built-in other than Object.preventExtensions/freeze/seal
that sets [[Extensible]] to false. When using the VirtualHandler, you only
need to override preventExtensions as freeze and seal depend on it.
> 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.
Our choice was to move away from grouping traps in this way. It's more
consistent (no irregularities in the API), and in cases where you do want
to distinguish between the two, it's a bit cleaner to separate it out into
two methods rather than switching on the string.
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.
Indeed, I should hook up proxies to iterators.
> "Non-interceptable operations"
> => I think that some are lacking:
> 1) Object.prototype.toString.call(proxy) (which reads the [[Class]])
> 2) "" + proxy (which reads the [[DefaultValue]](string))
> 3) (all operations which include a call to ToPrimitive)
Indeed, but it wasn't my intention to be exhaustive.
> 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).
Actually, the goal is for VirtualHandler and that implementation to be part
of the @reflect module itself.
> 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)
Fixed. Good catch!
> * "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) ?
Right again. The difference is important: if proto is itself a proxy, its
enumerate trap will be invoked rather than its getOwnPropertyNames trap.
This is a nice pattern: get, set, enumerate and has (all the traps that can
be invoked on proxies-as-prototypes) apply the corresponding Reflect
operation on the proxy's own prototype if the operation needs to proceed up
the prototype chain.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss