2015-10-22 21:03 GMT+02:00 Mark Miller <[email protected]>: > Ok, that all makes sense and is fine with me. Thanks for clarifying. > > Tom, I'm still curious what you remember? >
What I remember is that the original direct proxies spec did the transparent forwarding. wiki.ecmascript.org still seems to be down, but an archived copy of late 2014 (thank you Wayback Machine) shows that the draft spec indeed specified forwarding: < http://web.archive.org/web/20141214082226/http://wiki.ecmascript.org/doku.php?id=harmony:proxies_spec > *15.3.4.2 Function.prototype.toString ( O ) * When called on a Proxy that is callable (i.e. whose target has a [[Call]] internal method), returns the result of applying the built-in Function.prototype.toString on the Proxy’s [[Target]]. Otherwise, throw the same TypeError that would be thrown if this function is applied to a non-function object. For a revoked proxy, IsCallable is false so this operation throws a TypeError. I cannot recall any specific discussions on why that behavior was changed to throwing a TypeError instead. The only reason I can come up with is that it could be deemed a violation of the proxy's encapsulation in that it should not leak such details about its target object. I think it would be useful to at least reconsider the original forwarding behavior. I think that in practice, forwarding toString() to the target is not harmful, and the more places where code throws on a Proxy, the less useful Proxies become altogether. I noticed there is a stage 1 proposal to revise the specification of F.p.toString() < https://github.com/michaelficarra/Function-prototype-toString-revision>, including standardizing its behavior for host objects. Perhaps the behavior of F.p.toString() when applied to (function) proxies can become a part of this revision effort? Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
