Hello Jason, thank you for the explaination and answering my questions.
I understand you. If the proxies differ in behavior, they should not be transparent. But for our case we have multiple proxies representing the same target, only with different contracts. These contracts should e.g. give different access rights to the target. For this case it would be really good to compare not the proxies but the target, to see if the proxies are for the same target. For more informations see: http://dl.acm.org/citation.cfm?id=2508176 --- I've found the Algorithm for SameValue in the Interpreter.cpp. But where is the implementation for SameValueZero? >* BaseProxyHandler::nativeCall should delegate to the target object (instead of throwing an exception), if the proxy is transparent. This will make non-generic methods work. What do you mean with non-generic methods? I see the derived method nativeCall of the DirectProxyHandler is implemented to get the target. I don't understand in which case I have a DirectProxyHandler/ScriptedDirectProxyHandler or ScriptedIndirectProxyHandler and the parent BaseProxyHandler? Have I to change something in the "const Class js::ObjectProxyObject::class_"? I mean to add the new trap or something like this to make the new trap known to the system? Thanks a lot for your help Andreas Am Montag, 2. Dezember 2013 22:47:41 UTC+1 schrieb Jason Orendorff: > On 12/1/13 5:16 AM, schlegel.andr...@gmail.com wrote: > > > 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. > > > > Map and Set also distinguish proxies from their targets. So does > > instanceof. Generally search the ES6 specification for uses of SameValue > > and SameValueZero; those places test for object identity. > > > > > > > > Non-generic methods, such as the Number methods (but also Date, Map, and > > Set methods, and many others), also distinguish proxies from their > > targets, because they check for internal slots that are never present on > > proxies: > > > > " Unless explicitly stated otherwise, the methods of the Number > > prototype object defined below are not generic and the this value passed > > to them must be either a Number value or an object that has a > > [[NumberData]] internal slot that has been initialised to a Number value." > > > > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-properties-of-the-number-prototype-object > > > > > > > > Moreover, if the transparent proxy differs in behavior from the target > > in any observable way, then the two objects are distinguishable, period. > > They are not the same thing. That `a === b` can be hacked to return true > > is beside the point. At least, that's how it seems to me. > > > > (I would expect all proxies to differ in behavior from targets, at least > > potentially; otherwise why have a proxy?) > > > > > > > > All of which is to say: read Mark Miller's dissertation immediately, if > > you haven't already. > > > > http://www.erights.org/talks/thesis/index.html > > > > In my opinion, the only way to avoid the identity problem is to ensure > > that code that has a direct reference to a transparent proxy never also > > has a direct reference to its target. Mark's dissertation explains how > > to do this using membranes and compartments. It is a lucid, opinionated > > document, and a pleasure to read. > > > > But to skip all that and just answer your questions: > > > > > 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. > > > > > > [...] > > > > > > How can I integrate the new trap into the proxy? > > > > What you need to do is make sure the new trap is called from every place > > where you want the behavior to change. For example: > > > > * js::StrictlyEqual() would need to change. > > > > * Similarly, WeakMap_get and friends would have to take transparent > > proxies into account before querying the actual WeakMap data structure. > > > > * The same goes for MapObject::get_impl() and similar methods. > > > > * instanceof ends up in js::IsDelegate; the `if (obj2 == obj)` in that > > function will have to change. > > > > * BaseProxyHandler::nativeCall should delegate to the target object > > (instead of throwing an exception), if the proxy is transparent. This > > will make non-generic methods work. > > > > I'm pretty sure there is no easy shortcut. You'll just have to change > > all the individual places where identity matters. > > > > > > > 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? > > I'm afraid not. The purpose of that hook is hard to explain, but I'm > > sure it is not suitable for this use case. > > > > (I *think* the hook exists to allow certain system-internal weak data > > structures to be weaker than they would otherwise have to be. I don't > > entirely understand it, honestly, but I am 100% sure that it's not > > powerful enough to support what you're trying to do.) > > > > > Third Question: > > > --------------- > > > Is there a documentation for the Proxy API specific to the C++ > > implementation? > > > > No. :( > > > > -j _______________________________________________ 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
