2012/9/25 Waldemar Horwat <[email protected]> > > > Yes. This was bothering me during the meeting and (as far as I know) > didn't get resolved. What if someone passes in a proxy to a WeakSet > instead of an actual WeakSet? > > A. Allowed. Then the security protocol is utterly broken. > > B. Disallowed. Now we have a class that can't be proxied. > > Neither sounds good. What am I missing?
I intended option B. The whitelist can't be proxied. It's not that WeakSets can't be proxied in general (they can), but for the specific use of a WeakSet as a whitelist, the proxy needs a genuine WeakSet. This isn't all that different from DOM methods requiring genuine DOM elements, etc. I also don't see how membranes would require proxied whitelists: it would be weird to construct a Proxy whose whitelist must be a membraned object. I think of a newborn Proxy and its whitelist as being part of the same abstraction. It makes little sense to separate them by a membrane. I previously mentioned the alternative of making the WeakSet entirely hidden and introducing two built-in methods to manipulate them (Proxy.addName(proxy, name) and Proxy.removeName(proxy, name)). Then the problem of proxied whitelists goes away, but it precludes easy sharing of the same whitelist among multiple proxies, which seems like a reasonable thing to do. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
