The section on Lexical Scope has been done and now the course moves onto Execution contexts.
Execution contexts or in-memory-scopes differ from Lexical scopes in that they are built as the code runs, NOT as its typed.
The rules govern which variables the program has access to, at different points during the execution.
In-memory data scopes – as the program runs it will build up internal data storage for keeping track of all the variables that are available to different function objects.
Each new run of a function is meant to run in complete isolation from all previous runs, so a new execution context is created every time the function is run. So for each lexical scope there may be many in-memory scopes created during execution of the code.
Before the first line of code has been run the interpreter will set up an execution environment. As the first line of code runs, the interpreter builds up a new key value mapping inside the execution context in order to keep track of the value bound to the name of the first variable.
With the next line of code, a function assignment, a new key value pair is added to the global scope context.
Now the execution context looks like a collection of key value pairs, similar to an object. Its tempting to think that in-memory scopes and in-memory objects are the same thing. This is NOT so, and are kept separate by the interpreter. There are limits to the access to the execution context that do not exist for access to an object.
Many rules for objects are also true for execution contexts, but you CANNOT mix n’ match, despite the similarities they exist in two different worlds. For example you are not able to store an array full of contexts, even though you can do so for objects. Unable to iterate over the variable name in an execution context the way you can with keys in an object. Which means the interaction is different.
There is a lot to take in here, essentially objects and execution contexts are similar but not the same.