On 12/4/13 2:48 PM, Brendan Eich wrote:
Peter Thiemann wrote:
1. Contracts implemented using proxies. Adding a contract to a
program should never change the semantics of contract-abiding code -
if the contract is violated, it is of course fine to crash.
Meaning throw an exception, which could be caught? That seems like it
could require a program change.
Ideally, it should be an exception that cannot be caught by the code
under contract.
AFAIK, current implementations rely on user exceptions. I don't know
what Racket does.
Also, adding a contract to a program should not force you to change
something else in your program: a very useful pattern is to impose a
contract on code loaded at run time, say, a mashup. In this case, it
is very cumbersome to patch up this code to use a different equalp
(intercept the load, parse everything, rewrite the parse tree, etc)
and it has to be done for eval, too.
Mashups seem content with identity-preserving membranes, but I defer
to Mark.
2. Monitoring implemented using proxies. Here, you'd use the proxy to
record all gets and sets applied to an object, for example, to create
a replayable mock object. Again, adding monitoring should not change
the meaning of the program and you should not be forced to change the
code.
I would think such monitoring wrappers (I've written them) want only
the mock and never the object it wraps to escape to code that tests o
=== o. Identity-preserving membrane, with the monitored object only on
one side, the mock only on the other.
That sounds fine if you apply the wrapper globally, but what if you
apply it locally in the scope of an interesting function? In that case,
there is no clear boundary of what's left or right of the membrane, so
that the wrapped object could be compared with its unwrapped target.
-Peter
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
