On Mar 3, 2011, at 5:45 PM, Jeff Walden wrote: > On 03/03/2011 04:41 PM, Allen Wirfs-Brock wrote: >> I think your real question reduces to this: >> >> //none strict mode code >> globalObj= function() {return this}(); >> print(otherGlobal.eval("this") === globalObj) //?? >> >> The two different calls and the "indirect" name in your example may make the >> question seen like it is about something else (direct/indirect eval). > > Not quite so. For the example I gave, yes -- but you could see the > direct/indirect distinction by putting the code I provided inside a function > (and a little more gussying to demonstrate behavior better): > > var global = this; > function f() > { > var indirect = otherGlobal.eval; > eval = indirect; > print(eval("this") === this); > print(eval("this) === global); > print(eval("this") === otherGlobal); > print(indirect("this") === this); > print(indirect("this") === global); > print(indirect("this") === otherGlobal); > } > new f();
I tried to simplify because the above depends upon too many possible points of variation including whether you correctly are/aren't treating the first three calls as direct evals. That decision, itself may be subject to the answer to the test I suggested. So it is probably best to resolve that one first. the following would also be interesting to test: new function f() { var indirectEval = eval; var indirectForeignEval = otherGlobal.eval; print(indirectEval === indirectForeignEval); //see if they are the same object print(indirectEval("this") === indirectForeignEval("this")); //do they evaluate to the same global object? eval=indirectForeign; print(eval("this")===this); } > > IE9/Opera prints false/false/true and false/false/true. Chrome/Safari throws > EvalError every time. Firefox prints true/false/false and false/false/true > if otherGlobal is same-origin, false/false/true and false/false/true if > otherGlobal is different-origin-but-same-document.domain. > >> A more generally, do built-in functions capture their global environment at >> the time of their creation or do they they operate in the dynamic context of >> an ambient global environment. I hope it is the former. >> >> An example of the more general question would be: >> print((Object.getPrototypeOf(new otherGlobal.Array(0)) === Array.prototype) >> >> I believe the second example prints false for all browser implementations. > > This is an orthogonal issue, I believe, but I might as well respond since > it's being discussed. There's a Firefox 4 bug that makes this not the case, > ran out of time to fix it for release. It'll be fixed in 5.0, and I could > imagine I might get a fix for it in a 4.0 point release, although with a fast > release cycle that may not be necessary. If I recall correctly Nitro may be > buggy this same way as well. I think Chrome/IE9/Opera did not demonstrate > the bug in my testing. But in any case, printing false there is in my > opinion the correct behavior. I don't really agree that it is an orthogonal issue. The reason is because there are many places in the ES5 specification, including other built-in functions there the phrasing "standard built-in function" is used as well as the the phrase "the global object". When extending that specification to an environment that includes multiple global object, these phrases should still be consistently applied. If one built-in function works as if it was lexically bound to a specific global object while another use the current ambient global environment (whatever that might mean) then the implementation would seem to be internal inconsistent. The specification of direct eval is one of the places that use this phrasing in the spec.. so it is quite relevant whether an implementations is internally consistent in this regard. >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss