Open Bug 691894 Opened 8 years ago Updated 5 years ago
.prototype .eval, .eval With Bindings
No description provided.
This turned out to be something of a pain. - The front end isn't set up to handle compiling against a Call object. Only stack frames. This was pretty easy to fix. - ContextStack::pushExecuteFrame had to be rewired a bit to handle running against a Call object without a StackFrame. This was a bit touchy but I think I got it working. - It's impossible to recover the this-value for an execution context given only the lexical environment. The API is incomplete: the method should probably include a way to specify a this-value. - I am worried about DEFVAR and DEFFUN opcodes being emitted that could extend Call environments that the were previously assumed to be inextensible. I didn't try to fix this. - Deciding when to treat the eval code as strict mode (and thus introduce a new variable environment, like strict direct eval) turned out to be hard to specify nicely. - Need to do some more research to figure out how best to handle "arguments". ES5 says "arguments" is a binding in the call environment, but we don't actually implement it that way--at least, I *think* we never do. And I have vague misgivings about adding another vector into the interpreter. So this has been reclassified as a "future plan" for now. We may actually do it but it needs more thought than I can give it today.
You need to log in before you can comment on or make changes to this bug.