We need to revisit this behaviour and also add tests. The 'load-on-arbitrary-object' exposes a new kind of scope object to user code (apart from global object alone) - where global's properties are not available to user script but definitions from evaluated code go into a user accessible object. Even in the case of 'with' statement, global is always accessible within the with block. In strict mode, direct eval uses an intermediate 'scope' object which is not accessible to user code directly. Even in that case, function local scope objects are not accessible to user script. Direct 'eval' uses surrounding scope and surrounding 'this' - but only in non-strict mode. indirect 'eval' call always uses global object as 'this' as well as 'scope' object for evaluated code. This is very different anything else in the language/API.įor eg. In the above example, new 'bar' property is created in obj. Also, all definitions in the evaluated code go as properties. Trying to access 'Object' or 'print' from evaluated script results in ReferenceError/TypeError (calling 'undefined') etc. Load.call(obj, 'foo = 40 var bar = 'hello'') // obj.foo assigned!Īlso, the evaluated code can not access global variables. If 'load' builtin is called on global object or as a direct call, it uses global object as 'this' for the script evaluated as well as global object as 'scope' for evaluation.īut, if load is indirectly invoked with a different 'this' then that object is used as 'this' for evaluated code as well as 'scope' for the evaluated code.

Call of chernobyl scope bug