domenic at domenicdenicola.com (2013-12-03T03:04:39.553Z)
2013/11/27 David Bruant <bruant.d at gmail.com>
> Shouldn't it depend on the target's typeof value? depending on apply (not
> call) trap makes typeof unstable ("delete handler.apply").
> In any case, extra caution is required to keep typeof stability for
> revokable proxies (on revocation, maybe the value need to be saved
> somewhere)
No, the current ES6 draft I believe gets it right:
- typeof proxy does not depend on the presence of an "apply" trap, but on
whether the target object has a [[Call]] internal method. So deleting
handler.apply has no effect on the typeof value of the proxy. (see
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-typeof-operator-runtime-semantics-evaluation) (the current draft does lose the ability for a proxy to transparently
retain a non-standard typeof value. AFAICT, typeof proxy will always either
return "object" or "function")
- a proxy whose target has a [[Call]] internal method will itself have a
[[Call]] internal method. If the target does not have a [[Call]] internal
method, then neither does the proxy (see
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxycreate)
- revoking a revocable proxy does not change whether or not it has a
[[Call]] trap (see
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-revocation-functions), so the typeof result will remain stable even when the proxy is revoked.
> nit:
>
> "instanceof depends on the prototype chain"
> => Note that it calls the getPrototypeOf trap which doesn't enforce
> anything for extensible objects [1], so "*the* prototype chain" has a more
> volatile meaning for proxies than it has for regular objects.
Indeed, but only for proxies that claim to be extensible. For
non-extensible proxies, the prototype chain is well-defined.
2013/11/27 David Bruant <bruant.d at gmail.com> > Le 27/11/2013 19:14, Rick Waldron a écrit : >> >> >> BE: typeof depends if there is a call trap. instanceof depends on the >> prototype chain. All in the spec, so can create any object (apart from >> private state issues) >> > Shouldn't it depend on the target's typeof value? depending on apply (not > call) trap makes typeof unstable ("delete handler.apply"). > In any case, extra caution is required to keep typeof stability for > revokable proxies (on revocation, maybe the value need to be saved > somewhere) > No, the current ES6 draft I believe gets it right: - typeof proxy does not depend on the presence of an "apply" trap, but on whether the target object has a [[Call]] internal method. So deleting handler.apply has no effect on the typeof value of the proxy. (see < http://people.mozilla.org/~jorendorff/es6-draft.html#sec-typeof-operator-runtime-semantics-evaluation >) (the current draft does lose the ability for a proxy to transparently retain a non-standard typeof value. AFAICT, typeof proxy will always either return "object" or "function") - a proxy whose target has a [[Call]] internal method will itself have a [[Call]] internal method. If the target does not have a [[Call]] internal method, then neither does the proxy (see < http://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxycreate>) - revoking a revocable proxy does not change whether or not it has a [[Call]] trap (see < http://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-revocation-functions>), so the typeof result will remain stable even when the proxy is revoked. nit: > > "instanceof depends on the prototype chain" > => Note that it calls the getPrototypeOf trap which doesn't enforce > anything for extensible objects [1], so "*the* prototype chain" has a more > volatile meaning for proxies than it has for regular objects. > Indeed, but only for proxies that claim to be extensible. For non-extensible proxies, the prototype chain is well-defined. Cheers, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131127/c118884d/attachment.html>