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.
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.
In no case do I see JS == or === changing, in ECMA-262 or in an
accepted patch to SpiderMonkey.
No existing code would be broken by the change that we are proposing.
Even code with proxies will work the same as before. == and === for
objects will be slightly slower: we are going to evaluate by how much
and how it impacts overall performance. [we were thinking of using
JSBench for the evaluation, but any suggestion would be welcome]
Any slowdown is going to make a very hard sell, for any engine in the
current competitive browser market. We are pushing very close to safe
(SFI) native code speed with asm.js (compiled by Emscripten). Other
engines are just as picky.
Perhaps this won't be measurable, but planned slowdowns for non-proxy ==
and === tests won't fly.
/be
_______________________________________________
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
