Lexical Scope

[00:00:00]
>> Kyle Simpson: All right, so let's dig into lexical scope, let's take a look at this particular code. This should look familiar, this is the same kind of code that we were doing before. And at author time, when I decided to put the function ask inside of the function otherClass().

[00:00:13]
I irrevocably decided that the variable reference on line 7 is going to point at the variable that was declared on line 4. In other words the marble color was decided at compile time. It's not actually this look up process, like we discussed during the run time phase. I sort of fibbed when I used that in the narrative to give you a conceptual model.

[00:00:36]
But it is not the case that at run time it has to say hey, scope of ask, have you ever heard of this marble? And hey, scope of other class, have you ever heard of this marble? Because at least the way this program's written, we know at compile time what color the marble is.

[00:00:51]
And even in the worst case scenario, where we might for some reason not know what the color marble was from the compile time. We're gonna figure it out the very first time, and then we don’t need to figure it out ever again, cuz it’s never gonna change. So one of the reasons why lexical scope is actually so popular is because it’s so optimizable.

[00:01:12]
This idea that you can decide when you're compiling things, where all of those variables come from, what color the marbles are, we don’t need to figure that stuff out at runtime. That’s what you should get from lexical scope. One of the ways that helps me keep those boundaries in my head.

[00:01:27]
And it's also one of the reasons why I like writing out function expressions in their full form and nested rather than trying to string everything together on one line. Is I like to see the function boundaries and I like to mentally process that there's essentially a bubble around each of these scopes.

[00:01:43]
There's a bubble around ask, and a bubble around other class, and then a bubble around the global scope, and these bubbles are strictly nested inside of each other. So it's not like they're gonna cross the line. It's not like we're gonna have one scope that's partially in two parent scopes, they're entirely contained within each other.

[00:02:03]
As a matter of fact, visualizing these scopes inside of the bubbles, while it's kind of my preferred way of thinking about it. There's another way of visualizing this that is effective enough that it can actually show up inside of your editor. In my editor I use sublime, I think I've mentioned before.

[00:02:19]
In my editor, I have a plugin that I can switch on a mode. It uses a tool called ES levels, which is a tool that analyzes the scope levels of where basically all your buckets and marbles are. And this is what it looks like when I take that same piece of code and I turn it on inside of my editor.

[00:02:38]
You'll notice that it is coloring the different variable references and the different pieces of code according to what scope they belong to. It's basically giving you your bucket colors and your marble colors. And you'll notice down on line 7 that there's a color being referenced for teacher and that matches the one from line 4.

[00:03:00]
>> [INAUDIBLE]
>> Kyle Simpson: So again, this is a plugin that's called ES levels. Now, it is not perfect, it does have some quirks to it. If you notice this particular example, where I have a name function expression, remember what we talked about with the names of function expressions? Those names are supposed to go inside of their enclosing scope.

[00:03:22]
So why is that foo on line 1 colored as if it is in the outer scope? It would if it was a function declaration, but here they're doing that for a function expression. Years ago I reported this to the ES level's project, and said this is a bug that should be colored as if it belongs to the scope.

[00:03:42]
And they did a whole bunch of well, actuallys on, technically that name is in its own intermediate scope. And so it would even be right to give it the same colors, and then they went on this big long thing. And they'd say we'd have too many colors if we did it the real way, so we're just gonna leave it alone, we're just gonna leave it broken.

[00:04:02]
So it's not perfect, but it is super helpful at times to be able to see where are these variables coming from, or why am I getting so confused by these variables? So I'll flip that plugin in. But I like the idea of visualizing my scope boundaries. It helps me keep all of the lexical scopes straight.