Conversation
| 1. Set _env_.[[FunctionObject]] to _F_. | ||
| 1. Set _env_.[[ThisBindingStatus]] to ~uninitialized~. | ||
| 1. Let _home_ be _F_.[[HomeObject]]. | ||
| 1. Set _env_.[[HomeObject]] to _home_. |
There was a problem hiding this comment.
The above two steps could be coalesced.
| <h1>Environment Record Operations</h1> | ||
| <emu-clause id="sec-newclassstaticblockenvironment" aoid="NewClassStaticBlockEnvironment"> | ||
| <h1><ins>NewClassStaticBlockEnvironment ( _F_ )</ins></h1> | ||
| <p>The abstract operation NewClassStaticBlockEnvironment takes arguments _F_. It performs the following steps when called:</p> |
There was a problem hiding this comment.
| <p>The abstract operation NewClassStaticBlockEnvironment takes arguments _F_. It performs the following steps when called:</p> | |
| <p>The abstract operation NewClassStaticBlockEnvironment takes argument _F_ (a function object). It performs the following steps when called:</p> |
There was a problem hiding this comment.
We aren't very clear in the spec how to specify the types of arguments. For some cases we use (a function object), while for others we use 1. Assert: _F_ is an ECMAScript function., but we generally don't combine the two. I have the function assertion as the first line of the algorithm.
Note that this is based on https://tc39.es/ecma262/#sec-newfunctionenvironment, which uses only the assertion.
There was a problem hiding this comment.
Yes, this is true, it is not great to give a more general type and then assert that it is a more specific type in the assert, even if it's not incorrect in how it's used.
| 1. Assert: _innerContext_ is now the running execution context. | ||
| 1. Perform ClassStaticBlockBindThis(_F_, _innerContext_). | ||
| 1. Let _result_ be ClassStaticBlockEvaluateBody(_F_). | ||
| 1. Let _result_ be ClassStaticBlockEvaluateBody(|ClassStaticBlockBody|). |
There was a problem hiding this comment.
This is a bit weird, but we can address it later.
There was a problem hiding this comment.
How is this weird? We call AOs with parse nodes in other places in the spec. For example, the use of IsAnonymousFunctionDefinition here:
https://tc39.es/ecma262/#sec-object-initializer-runtime-semantics-propertydefinitionevaluation
There was a problem hiding this comment.
It's weird in that I'd like a sharper line dividing runtime SDOs and AOs. And agreed that this is an existing oddity, thus no need to act on it now.
# Conflicts: # docs/index.html

Address early editor review feedback from #22.