2013/1/23 Brendan Eich <[email protected]> > Brandon Benvie wrote: > >> It is my opinion that the primary use case for private symbols is for >> properties that proxies expressly shouldn't be given a chance, in any >> manner, to corrupt or modify. They are likely used for sensitive internal >> state that will only be accessed by methods or friend classes created in >> service of the target. >> >> A membrane becomes less valuable if breaking the target is an easily >> accomplished accidental side effect. This is already visible in practice >> today when you attempt to use WeakMaps to create private state for objects >> and they are proxied, since the private state will be keyed on `this` in >> the constructor which won't match `this` in methods invoked on the proxy. >> > > ding ding ding ding ding ding....
Let's try to separate the issues here: 1) proxies and private symbols: Brandon strengthens the case that proxies should be oblivious to private symbols. 2) any sort of private state (regardless of whether it's stored using private symbols or weakmaps) is always keyed off of the identity of the target. 3) because of JS's "invoke = get + apply" semantics, by default a proxy always leaves the |this| value pointing at the proxy. The combination of 2) and 3) is problematic (as in: not transparent). Looking only at 3), sometimes this is what you want, and sometimes it isn't. In the case of membranes I agree the more natural thing to do is to rebind |this| to the real target, not a membraned proxy for it. I think membranes can do that already without added cost: the "get" trap already needs to return a wrapper for the actual function object anyway. That wrapper, when called, can call the real function with the real target as the |this| value. Looking back at the code for an identity-preserving membrane < http://wiki.ecmascript.org/doku.php?id=harmony:proxies#an_identity-preserving_membrane> I think this membrane actually properly unwraps the |this| value before forwarding. I haven't yet tried expressing this code using Direct proxies, but off the top of my head I don't see how the change from proxies to direct proxies would impact this particular aspect of membranes. So 3) may be an issue in general, but membranes should be able to avoid it. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
