On Tue, Dec 3, 2013 at 7:18 AM, Mark Miller <[email protected]> wrote:
> Tom and I are in two overlapping conversation threads about the same > issue: Membranes vs Contracts vs Identity. If no one here objects soon, > I'll forward each thread so far to this joint thread and then reply on this > joint thread to all the addressees. > > This joining request will turn out to be ironically related to the subject > matter we're discussing ;). > And now the thread with Andreas Schlegel and Brendan Forwarded conversation Subject: Fwd: [JS-internals] Transparency of JavaScript Proxies ------------------------ From: *Brendan Eich* <[email protected]> Date: Sun, Dec 1, 2013 at 4:04 AM To: [email protected] Cc: "Mark S. Miller" <[email protected]> This just came in on the SpiderMonkey internals dev list -- can you provide guidance? Feel free to bounce to es-discuss. Thanks, /be Begin forwarded message: *From:* [email protected] *Date:* December 1, 2013 at 11:16:56 AM GMT *To:* [email protected] *Subject:* *[JS-internals] Transparency of JavaScript Proxies* Hello, I'm a student at the university of Freiburg. I write my master thesis about transparency of JavaScript proxies. The topic is, that the proxies are not really transparent, because the Equal-Operators (== and ===) compare the references of the proxies and not of the targets. Also the WeakMap uses the proxy as key and don't allow the target also as key, if a proxy was inserted. First Question: --------------- I should implement an addition for the Proxy API in form of a new Handler Trap, which says if a proxy is really transparent or not. The trap should look like this: var handler = { isTransparent: function(){ return true; } }; With this trap I should change the operators for comparing either the target or the proxy, dependent of the result of the trap. I've implemented the following Methods for the BaseProxyHandler and Proxy: bool BaseProxyHandler::isTransparent(JSContext *cx, HandleObject proxy, bool *bp) { return Proxy::isTransparent(cx, proxy, bp); } bool Proxy::isTransparent(JSContext *cx, HandleObject proxy, bool *bp) { JS_CHECK_RECURSION(cx, return false); return proxy->as<ProxyObject>().handler()->isTransparent(cx, proxy, bp); } How can I integrate the new trap into the proxy? I've found the "const Class js::ObjectProxyObject::class_" must I do an new entry for the trap? Second Question: --------------- I've found the "static JSObject * proxy_WeakmapKeyDelegate(JSObject *obj)". Can I make a trap to use a Proxy as key in a WeakMap but use the target to get the value with this method? Third Question: --------------- Is there a documentation for the Proxy API specific to the C++ implementation? Thanks a lot Andreas Schlegel _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals ---------- From: *Tom Van Cutsem* <[email protected]> Date: Mon, Dec 2, 2013 at 9:10 AM To: [email protected] Cc: "Mark S. Miller" <[email protected]>, Brendan Eich <[email protected]>, [email protected] Hello Andreas, I'm not going to give implementation-level advice but as one of the designers of the Proxy API rather some high-level feedback on your proposal: I assume you're working with prof. Peter Thiemann who has been using proxies to implement contracts in JavaScript, so I think I know where you're coming from. Nevertheless, I'm not sure whether your goal of allowing proxies to intercept the '==' and '===' operators _in general_ makes much sense. Consider: var target = { x: 42 }; var p1 = new Proxy(target, { isTransparent: function() { return true; } }); // a transparent forwarding proxy var p2 = new Proxy(target, {get: function() { throw new TypeError(); } }); In this case, p1.x === 42 p2.x // throws TypeError Yet, you want to make it possible for p1 and p2 to be identity-equal (if they implement your isTransparent() trap). I believe this will go against the expectations of most code, which assumes that if p1 and p2 are identity-equal, one should be able to substitute p1 for p2 without any observable difference. Is it really necessary to make a general extension to proxies to make your use case work? Best regards, Tom ---------- From: *Andreas Schlegel* <[email protected]> Date: Mon, Dec 2, 2013 at 10:36 AM To: Tom Van Cutsem <[email protected]> Cc: "Mark S. Miller" <[email protected]>, Brendan Eich <[email protected]>, [email protected] Hello Tom, you're right I'm working with prof. Peter Thiemann. The intention was to compare the targets not the proxy, if the isTransparent trap is set, but your right I haven't observed your case. But I think also the developer have to decide, if he want to implementation the trap. The problem of prof. Peter Thiemann is, that the Proxies aren't really transparent and in an environment with multiple proxies for one target he cannot compare them. I think also it would be nice to give an alternative with an really transparent proxy. In my opinion this could also be a new variation of proxies, but this is my opinion. Is it eventually possible to include a check for the isTransparent trap into the get trap to get either the target, if wanted, or the error? At the moment I've changed the LooselyEqual and StrictlyEqual methods of the Interpreter.cpp to get the target instead of the proxy. But after a chat in the jsapi IRC today, I know I need to change a lot more in the JIT to get all Fast Path cases for == and ===. If there is a way to change only a part of the Proxy API instead, e.g. the get trap, to get the target, if wanted. It would be really nice. Thank you for your feedback, I hope I don't work against your opinion. Best regards, Andreas Am 02.12.2013 18:10, schrieb Tom Van Cutsem: ---------- From: *Mark S. Miller* <[email protected]> Date: Mon, Dec 2, 2013 at 12:15 PM To: Andreas Schlegel <[email protected]> Cc: Tom Van Cutsem <[email protected]>, Brendan Eich <[email protected]>, [email protected] Why not use the identity-preserving membrane pattern? -- Cheers, --MarkM ---------- From: *Tom Van Cutsem* <[email protected]> Date: Tue, Dec 3, 2013 at 1:45 AM To: "Mark S. Miller" <[email protected]> [private] 2013/12/2 Mark S. Miller <[email protected]> > Why not use the identity-preserving membrane pattern? > I believe the problem Peter Thiemann is running into is similar to the problem Jeremy Siek and Phil Wadler are running into: they may have multiple proxies (representing multiple, different contracts), to the same target object. Even with identity-preserving membranes, there will be multiple distinct contract-wrappers, and it's not always clear whether and how the contracts can be merged into a single proxy. It's interesting that two independent groups of researchers have run into this same problem. Still, I think the solution lies in smarter contracts, not in weakening object identity. Cheers, Tom ---------- From: *Tom Van Cutsem* <[email protected]> Date: Tue, Dec 3, 2013 at 3:08 AM To: "Mark S. Miller" <[email protected]> Cc: Andreas Schlegel <[email protected]>, Brendan Eich < [email protected]>, [email protected] 2013/12/2 Mark S. Miller <[email protected]> > Why not use the identity-preserving membrane pattern? > I believe the issue is that they have different "contract" proxies pointing to the same target object. Even with the membrane pattern, you would have distinct wrappers, one for each type of contract. To obtain identity on both sides of the membrane, the "contract" proxies would need to be merged (e.g. by taking the union of the 2 contracts, if that's at all possible). I believe the open research question here is when and how contracts could be merged to preserve strong object identity (because the merged contracts can be represented by just a single proxy). I don't think weakening object identity (which is the current proposal we're debating) is going to really improve things. Cheers, Tom ---------- From: *Andreas Schlegel* <[email protected]> Date: Tue, Dec 3, 2013 at 6:33 AM To: Tom Van Cutsem <[email protected]>, "Mark S. Miller" < [email protected]> Cc: Brendan Eich <[email protected]>, [email protected] Hello, yes you're right, the problem of the contracts researched by prof. Thiemann was, that the targets behind the proxies could not be compared by == and ===. How can I merge contracts of multiple proxies and represent them by just a single proxy, if I cannot compare them (or get the target)? We have discussed first an approach with new operators spezific to proxy comparism but this is not the way. If I can include a trap for asking the proxy if he's transparent or not, it is possible to use the same operators by asking the proxy. Best regards Andreas _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
