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 Am 03.12.2013 12:08, schrieb Tom Van Cutsem: > 2013/12/2 Mark S. Miller <erig...@google.com <mailto:erig...@google.com>> > > 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 > > > > > On Mon, Dec 2, 2013 at 10:36 AM, Andreas Schlegel > <schlegel.andr...@gmail.com <mailto:schlegel.andr...@gmail.com>> > wrote: > > 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: >> 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 >> >> 2013/12/1 Brendan Eich <bren...@mozilla.com >> <mailto:bren...@mozilla.com>> >> >> 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:* schlegel.andr...@gmail.com >>> <mailto:schlegel.andr...@gmail.com> >>> *Date:* December 1, 2013 at 11:16:56 AM GMT >>> *To:* dev-tech-js-engine-internals@lists.mozilla.org >>> <mailto:dev-tech-js-engine-internals@lists.mozilla.org> >>> *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 >>> dev-tech-js-engine-internals@lists.mozilla.org >>> <mailto:dev-tech-js-engine-internals@lists.mozilla.org> >>> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals >> >> > > > > > -- > Cheers, > --MarkM > > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
