Le 04/12/2013 15:52, Peter Thiemann a écrit :
On 12/03/13 23:32, Mark Miller wrote:
On Tue, Dec 3, 2013 at 2:06 PM, Peter Thiemann
<[email protected]
<mailto:[email protected]>> wrote:
On 03.12.2013, at 22:09, Mark Miller <[email protected]
<mailto:[email protected]>> wrote:
----------
From: *Andreas Schlegel* <[email protected]
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]>>
Date: Tue, Dec 3, 2013 at 6:33 AM
To: Tom Van Cutsem <[email protected]
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]>>,
"Mark S. Miller" <[email protected]
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]>>
Cc: Brendan Eich <[email protected]
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]>>,
[email protected]
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]>
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.
Yes, for JS or any language where identity is based on an
equality *predicate*, it is too late: The conflict between
contracts and identity can't be fixed. Note that, through my lack
of foresight about this issue, E is among the languages that
can't be fixed.
Actually, I don't think it is too late. We have come up with a
design where the proxy's handler can determine whether equality is
opaque or transparent - this is what Andreas is currently trying
to implement. This way, you may create proxies with different EQ
semantics while still guaranteeing that EQ is an equivalence
relation.
There is much here that I did not understand: What is "transparent"
vs "opaque" equality? How can it be up to the handlers to determine
this, on the one hand, but still guarantee that it is an equivalence
relation, on the other hand? These two seem to be in conflict.
Transparent equality: EQ recursively dereferences proxies to their
ultimate non-proxy targets and compares those.
Opaque equality: EQ directly compares, i.e., the current state of
affairs in JS.
Consider
var p = new Proxy ( target, handler);
The trick is *not* to trap equality, but to let the handler control
whether EQ dereferences p to target before comparing pointers. Notice
that one handler only controls one step of dereferencing. If target is
a proxy, again, then EQ recursively asks that proxy's handler until
either a non-proxy object is reached *or* the handler does not request
further forwarding.
Here is an outline of the proposal:
http://proglang.informatik.uni-freiburg.de/projects/JSProxy/proxy.pdf
From reading this thread I feel I'm severely lacking the proper
background, but I'd like to try a question anyway.
1.3 Use Case: Contracts:
During maintenance, the programmer may add contracts to a program as
understanding improves.
What does "add contracts" mean? "Add" contracts to a given
object/function which already have one? Add contracts to things that
didn't have any beforehand?
Clearly, the addition of a new contract must not change a program
execution that respects the contract already.
Agreed.
In this scenario, the program executes in a mix of original objects
and proxy objects.
I don't understand why. The way I see it, an object with a contract is
an object replaced in the runtime by a proxy which handler implements
the contract. When I write "replace", I mean that the object constructed
as a proxy. Otherwise, there are places where the contract can't and
won't be enforced.
By my definition, the original object is only available to the proxy as
its target and no other context. Also, even if piling contracts, only
one proxy is available in the end (previous proxy becomes target of next
contract proxy).
Or is the contract different based on where the object is sent? If the
answer is yes, is it really the same object? Isn't it rather a façade to
the target (and should effectively be a different object, most likely a
proxy)
Thanks,
David
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
