Hello,
here is the evidence for our use case after consulting prof. Thiemann:
The current design is geared towards one use case of proxies in JavaScript,
compartmenting execution with the membrane pattern where each program part
either sees only proxy objects (e.g., the foreign code against which we want to
protect)
or only original objects (e.g., the underlying local application code).
But there are use cases, where proxies should be transparent.
For example, when using proxies to implement a contract system, like Tim
Disney's
contract implementation, then there are situations where proxies and original
objects
are both manipulated by the same code.
Why do we want proxies to be transparent with respect to equality in this case?
A typical use of contracts is to gradually add contracts to a program while a
programmer
gains understanding of the program. In this process, it is crucial that the
contract-
respecting behavior of the program does not change. In particular, equality
should not
be affected by inserting contracts. (For similar reasons, Racket's proxies -
called
chaperones and impersonators - are transparent. see [1[)
Here is a concrete example:
function f(x, y) {
if (x === y){
return "something";
} else {
return y.foo;
}
}
var g = ... apply a function contract to f such that x is unrestricted and y
must be an object with a "foo" property ... [can be written with Disney's
library]
var o = {foo: "anything"};
f (o, o) === "something";
// but
g (o, o) === "anything";
so, using the contracted version of f changes the meaning of the program.
More discussion may be found in this draft paper:
http://proglang.informatik.uni-freiburg.de/projects/JSProxy/proxy.pdf
[1] T. S. Strickland, S. Tobin-Hochstadt, R. B. Findler, and M. Flatt.
Chaperones and impersonators: run-time support for reasonable interposition. In
OOPSLA, pages 943–962. ACM, 2012.
proxy.dvi
-Peter Thiemann
Best regards
Am Dienstag, 3. Dezember 2013 15:19:33 UTC+1 schrieb Brendan Eich:
> Andreas Schlegel wrote:
>
> > 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.
>
>
>
> Could you give evidence (a compelling example) or some argument for this
>
> claim? I don't see why contract-proxies that differ (provide different
>
> "views" if you will) should be ==, === or any kind of equal, just
>
> because they view the same target.
>
>
>
> /be
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
