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
