This is a section of slebetman’s answer to the question javascript can’t access private properties that answers your question very well.
The Stack:
A scope is related to the stack frame (in Computer Science it’s called
the “activation record” but most developers familiar with C or
assembly know it better as stack frame). A scope is to a stack frame
what a class is to an object. By that I mean that where an object is
an instance of a class, a stack frame is an instance of scope.Let’s use a made-up language as an example. In this language, like in
javascript, functions define scope. Lets take a look at an example
code:var global_var function b { var bb } function a { var aa b(); }
When we read the code above, we say that the variable
aa
is in scope
in functiona
and the variablebb
is in scope in functionb
.
Note that we don’t call this thing private variables. Because the
opposite of private variables are public variables and both refer to
properties bound to objects. Instead we callaa
andbb
local
variables. The opposite of local variables are global variables
(not public variables).Now, let’s see what happens when we call
a
:
a()
gets called, create a new stack frame. Allocate space for local
variables on the stack:The stack: ┌────────┐ │ var aa │ <── a's stack frame ╞════════╡ ┆ ┆ <── caller's stack frame
a()
callsb()
, create a new stack frame. Allocate space for local
variables on the stack:The stack: ┌────────┐ │ var bb │ <── b's stack frame ╞════════╡ │ var aa │ ╞════════╡ ┆ ┆
In most programming languages, and this includes javascript, a
function only has access to its own stack frame. Thusa()
cannot
access local variables inb()
and neither can any other function or
code in global scope access variables ina()
. The only exception are
variables in global scope. From an implementation point of view this
is achieved by allocating global variables in an area of memory that
does not belong to the stack. This is generally called the heap. So to
complete the picture the memory at this point looks like this:The stack: The heap: ┌────────┐ ┌────────────┐ │ var bb │ │ global_var │ ╞════════╡ │ │ │ var aa │ └────────────┘ ╞════════╡ ┆ ┆
(as a side note, you can also allocate variables on the heap inside
functions using malloc() or new)Now
b()
completes and returns, it’s stack frame is removed from the
stack:The stack: The heap: ┌────────┐ ┌────────────┐ │ var aa │ │ global_var │ ╞════════╡ │ │ ┆ ┆ └────────────┘
and when
a()
completes the same happens to its stack frame. This is
how local variables gets allocated and freed automatically – via
pushing and popping objects off the stack.Closures:
A closure is a more advanced stack frame. But whereas normal stack
frames gets deleted once a function returns, a language with closures
will merely unlink the stack frame (or just the objects it contains)
from the stack while keeping a reference to the stack frame for as
long as it’s required.Now let’s look at an example code of a language with closures:
function b { var bb return function { var cc } } function a { var aa return b() }
Now let’s see what happens if we do this:
var c = a()
First function
a()
is called which in turn callsb()
. Stack frames
are created and pushed onto the stack:The stack: ┌────────┐ │ var bb │ ╞════════╡ │ var aa │ ╞════════╡ │ var c │ ┆ ┆
Function
b()
returns, so it’s stack frame is popped off the stack.
But, functionb()
returns an anonymous function which capturesbb
in a closure. So we pop off the stack frame but don’t delete it from
memory (until all references to it has been completely garbage
collected):The stack: somewhere in RAM: ┌────────┐ ┌╶╶╶╶╶╶╶╶╶┐ │ var aa │ ┆ var bb ┆ ╞════════╡ └╶╶╶╶╶╶╶╶╶┘ │ var c │ ┆ ┆
a()
now returns the function toc
. So the stack frame of the call
tob()
gets linked to the variablec
. Note that it’s the stack
frame that gets linked, not the scope. It’s kind of like if you create
objects from a class it’s the objects that gets assigned to variables,
not the class:The stack: somewhere in RAM: ┌────────┐ ┌╶╶╶╶╶╶╶╶╶┐ │ var c╶╶├╶╶╶╶╶╶╶╶╶╶╶┆ var bb ┆ ╞════════╡ └╶╶╶╶╶╶╶╶╶┘ ┆ ┆
Also note that since we haven’t actually called the function
c()
,
the variablecc
is not yet allocated anywhere in memory. It’s
currently only a scope, not yet a stack frame until we callc()
.Now what happens when we call
c()
? A stack frame forc()
is
created as normal. But this time there is a difference:The stack: ┌────────┬──────────┐ │ var cc var bb │ <──── attached closure ╞════════╤──────────┘ │ var c │ ┆ ┆
The stack frame of
b()
is attached to the stack frame ofc()
. So
from the point of view of functionc()
it’s stack also contains all
the variables that were created when functionb()
was called (Note
again, not the variables in function b() but the variables created
when function b() was called – in other words, not the scope of b()
but the stack frame created when calling b(). The implication is that
there is only one possible function b() but many calls to b() creating
many stack frames).But the rules of local and global variables still applies. All
variables inb()
become local variables toc()
and nothing else.
The function that calledc()
has no access to them.What this means is that when you redefine
c
in the caller’s scope
like this:var c = function {/* new function */}
this happens:
somewhere in RAM: ┌╶╶╶╶╶╶╶╶╶┐ ┆ var bb ┆ └╶╶╶╶╶╶╶╶╶┘ The stack: ┌────────┐ ┌╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┐ │ var c╶╶├╶╶╶╶╶╶╶╶╶╶╶┆ /* new function */ ┆ ╞════════╡ └╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶┘ ┆ ┆
As you can see, it’s impossible to regain access to the stack frame
from the call tob()
since the scope thatc
belongs to doesn’t
have access to it.