-
Notifications
You must be signed in to change notification settings - Fork 482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reducing reliance on fnGlobalObject.js #568
Comments
Agreed.
+1 to keep the helper If it helps, the normative text for the global
|
Resolved via gh-595 |
While reviewing gh-567: "Add
System.global
tests", I was about to suggest the use of thefnGlobalObject
helper function instead of a simplethis
reference to test the property value.I'm not sure this is necessary, though, and really, I'm not sure
fnGlobalObject
is necessary in any case that Test262 currently uses it.Test runners are required to execute test contents in the global scope--anything else would invalidate certain tests. The
this
keyword has long (always?) been specified as returning the global object when evaluated in global code.If this is true, I would be in favor of simplifying the ~200 tests that include
fnGlobalObject.js
to referencethis
directly, and (more importantly) reducing the domain-specific knowledge required to author new tests.I'd like to keep the helper around, though, because it will still be necessary for accessing the global from module code (see gh-562: "Module semantics: declaration instantiation"), and it seems possible that security restrictions (e.g. CSP in web browsers) may lead some consumers to look for a mechanism to override that function.
If there is some detail that I'm overlooking, then I'm happy to leave the usage as-is (although I may want to document the use case(s) as an in-line comment in
fnGlobalObject.js
itself).From ES5's 11.1.1 The this Keyword:
And from 10.4.1.1 Initial Global Execution Context:
The text was updated successfully, but these errors were encountered: