Skip to content
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

Closed
jugglinmike opened this issue Apr 4, 2016 · 2 comments
Closed

Reducing reliance on fnGlobalObject.js #568

jugglinmike opened this issue Apr 4, 2016 · 2 comments

Comments

@jugglinmike
Copy link
Contributor

While reviewing gh-567: "Add System.global tests", I was about to suggest the use of the fnGlobalObject helper function instead of a simple this 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 reference this 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:

The this keyword evaluates to the value of the ThisBinding of the current
execution context.

And from 10.4.1.1 Initial Global Execution Context:

The following steps are performed to initialize a global execution context
for ECMAScript code C:

  1. Set the VariableEnvironment to the Global Environment.
  2. Set the LexicalEnvironment to the Global Environment.
  3. Set the ThisBinding to the global object.
@leobalter
Copy link
Member

If this is true, I would be in favor of simplifying the ~200 tests that include fnGlobalObject.js to reference this directly, and (more importantly) reducing the domain-specific knowledge required to author new tests.

Agreed.

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.

+1 to keep the helper

If it helps, the normative text for the global this changed but the value is the same:

8.1.1.4.11 GetThisBinding ()

1. Let envRec be the global Environment Record for which the method was invoked.
2. Return envRec.[[GlobalThisValue]]. 

@jugglinmike
Copy link
Contributor Author

Resolved via gh-595

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants