Hello Mark,
my understanding of the identity-preserving membrane pattern is a one to one
relation from proxy to target, I'm right?
In our case we could have multiple proxies for one target, this should blow up
the WeakMaps inside, if I think correctly.
Or can you explain me the usage for this case?
Best regards
Andreas
Am Montag, 2. Dezember 2013 21:15:26 UTC+1 schrieb Mark S. Miller:
> Why not use the identity-preserving membrane pattern?
>
>
>
>
>
> On Mon, Dec 2, 2013 at 10:36 AM, Andreas Schlegel <
>
> 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>
>
> >
>
> >> 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
>
> >> *Date:* December 1, 2013 at 11:16:56 AM GMT
>
> >> *To:* 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
>
> >> 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
