Closure Clarifications & Review

[00:00:00]
>> Will Sentance: What are the names we can call this backpack that we've given new function, so that it has a permanent memory. I love that, I love it now when we run that function, it's got this little temporary local memory sure, but it's also this little permanent memory attached to it.

[00:00:13]
Two memories, two stores of data behave differently, one individually to each function being each function call. The other protected and preserved and available to every function call to new function by what you might will be thinking, hold on. How does this fit into our functional goals? Well, I'll tell you in a second, but what are the fancy names of the backpack?

[00:00:34]
They're really fancy. So, there is this. This is data, it is persistent, it persists as long as it's function is saved. If we were to delete this function, the backpack gets deleted. If we were to reassign this function, which we couldn't do with a const declaration anyway, but it would be deleted.

[00:00:50]
But it's persistent data, okay fine, the data is referenced by a scope property. What does scope mean? Scope is the fancy name in programming for any given line of my code, what data do I have access to at that point? Just a fancy word for when I do this line, when I run this line what data is available to me?

[00:01:18]
So, this is the data, which when I run new function, it has available to it. So, it's good but it's a special type of scope. Here, the data I have available to me, is the data that was available to me when that function was initially saved in memory.

[00:01:36]
When it was initially saved, the date around. Forever more that function will have access to that data, why? Because it's going to pull it out along with it wherever it goes. And that is known as lexical or static scope. It is fixed, it's static, it's fixed from when we save the function is lexical, in the sense that where we position the saving of the function on the page determines what data is available whenever we end up running the function.

[00:02:02]
As contrasted to dynamic scope, which says the only data that will be available to when you run a function is a data that's there when you're running the function. Instead, here, the data that is available to us is a data from when the function was initially saved, because we pull the function out, and we brought the data with it.

[00:02:19]
So, we can call this, you want to get really fancy? Persistent lexical scope referenced data, another name for it, slightly less verbose, but by the way you say this in interviews. [SOUND] They're going to roll the red carpet out. They're going to, I mean the truth is I comments injuries again because people want video now comments, enjoys.

[00:02:42]
But they're going to give you their job. So, there it is, position let's see, so reference data but there's another name for it, which is, this local memory can sometimes also be known as the variable, this is one name for it. The variable environment. That is to say the environment is stuff around me, right?

[00:03:08]
And these are the variables around me inside that function. We said this earlier. We talk about that variable environment being closed over. We grab it, hold on to it and return it out. They call this backpack, also the closed over variable environment or the cove. Do you see now why I call it?

[00:03:30]
I think, it's the best name, the backpack, what a name. [INAUDIBLE] but developers colloquially tend to call this persistent memory attached to our function definition when it was born inside the running of another function. And returned out and grabbed all its data that should have been deleted, but instead is attached on the back of the function, persistent.

[00:03:58]
They call this backpack, the closure. I love the name because, they also call the overall concept closure. But you'll hear developers, which is being ambiguous. You'll here developers say, put that data in the functions closure. And people this ends up being used everywhere in JavaScript. When you pass a function to an asynchronous call back into an asynchronous API call, you pass that function in.

[00:04:34]
When it ends up being able to run later on go, what's the hard parts of Asynchronous JavaScript, when has been running wrong, it has always data from when it was born. Where? In the backpack. My favorite one, generators, generators have functions that are plausible and not possible. You just remembered when you finish running, when you start running them, you remembered what line you were on and all the data at that point in the local memory in that backpack.

[00:05:00]
So, when you started again, you grab all the data and the code line you wanted the function, continue running and grab the data in the backpack. They don't rate it where you run a function to enable you to each time you run the function, get data out of an array element by element.

[00:05:19]
You've seen it's rated the first time around the function it grabs the first item from the array returns out next time, next element, next time, next element. How's it remembering where it's at in the array? The function has stood, counter on which elements its own in his backpack, and the underlying data as well.

[00:05:38]
For these dominate, and we're going to use it in functional programming in very, very powerful ways.
>> Charles: Is closure synonymous with lexical scope, or closures is the larger?
>> Will Sentance: That's the thing, people who I think are ambiguously developers call the overall concept, closure. I personally as a really great question is actually literally as my favorite way to say.

[00:06:04]
Thank you, Charles. I like to say, lexical scoping is the concept that functions get a connection to their surrounding memory in which they were saved. You then wherever you end up running that function, wherever you end up passing that function, moving it around your application. It always brings with it.

[00:06:26]
I say backpack, but that's due to the lexical scope feature of JavaScript, which is that functions immediately get a scope reference in their surrounding variable environment and pull that out wherever you go. Lexical scope is the feature of the programming language that keeps data attached the function of where it saved.

[00:06:43]
Closure is this ambiguous wooly term that refers to, it's used to refer to the backpack. It's used to refer to the lexical scoping principle. And it's used to refer to the whole thing together. So, I think, lexical scope is a really good name to describe the feature that enables the backpack to exist.

[00:07:03]
Yeah, very nice question, Eric.
>> Eric: How does nesting affect-
>> Will Sentance: Yeah.
>> Eric: What's included in the backpack, you got another layer of nesting?
>> Will Sentance: Sure, backpacks get passed along, they are permanently attached to the function. Go play with how that works layers in, but yeah, it's as you expect.

[00:07:22]
Sam.
>> Sam: Okay so, because closure can mean the thing that's being closed over or the technique of closing,
>> Will Sentance: Yeah, and the principle that enables that closing to happen, right? Yeah.
>> Sam: I have tended toward using closure to refer to the technique whereas context is the term that I tend to use for lexical scoping, is that incorrect?

[00:07:50]
>> Will Sentance: I wouldn't say is incorrect then, [INAUDIBLE] correct. I would just say people will use context also wait for it, to refer to a functions, this keyword assignment, which is another totally different thing. So, it's enough that, whenever you sort of agree with your team, you use to refer to these things, you're fine.

[00:08:10]
But I would argue that because people use the word, context, often to refer to this, this keyword assignment inside a function, execution context. I think context is too general a term, usually.
>> Sam: Execution context would clarify that, and be more appropriate, or it's still wrong?
>> Will Sentance: But execution context is both the memory and the fact that the threat is currently running that code, whereas, we just taking the local memory the variable environment and closing over it and persisting it.

[00:08:40]
This is the execution context, it's the local memory plus the thread. This is not an execution context, this is just the persisted local memory.
>> Sam: The backpack.
>> Will Sentance: Very nice of you Sam, the backpack. Seth?
>> Seth: We've got a whole bunch of expensive work inside outer, and it's not referenced inside increment counter, that does not come along inside the backpack.

[00:08:59]
>> Will Sentance: When you say expense work, you mean if we saved like massive arrays of arrays.
>> Seth: Yeah
>> Will Sentance: Yeah, no it's all left behind unless the returned out function. And you can recount a now newFunction makes reference to all of that expensive work. In which case, you want it to be there because otherwise you could try to refer to it inside of newFunction and it's gone, which would be bad.

[00:09:17]
Closure in functional JavaScript, easier to add features. Our functions can now have persistent permanent memories attached to them. It's going to make them dramatically more powerful. Easy to do both, [SOUND] I don't know, definitely not. Unless, you know how it's working under the hood. Now, there's something I want to say here, in functional programming, we want every function called to be independent.

[00:09:41]
Meaning, if I'm running this function, and then I'm running it again, and it's got a permanent memory, even if it can encapsulate, well, I shouldn't say that, protected inside the function execution context. I'm still basically making my functions, I can't look at them and know they're going to behave exactly the same way.

[00:09:59]
And that line is, [INAUDIBLE] the line, and I can't look at them and go, [SOUND], fantastic. I know exactly what function is doing, because it's got to be not global side effects, still a degree of side effects. There's two things to say about this. In the strict implementation of functional programming, sorry, closure in functional programming, we actually fix this data that it can't be changed.

[00:10:24]
And therefore, all we really have is a permanent, persistent store of data here that we're never interacting with again, and changing. Meaning, but we'll come to this in a bit more detail in a moment, meaning our functions are all still pure. But I also want to say in general, functional programming is going to be an aspiration, especially in JavaScript.

[00:10:43]
It's not strictly implemented in JavaScript end to end. Meaning, even if we don't perfectly conform to every single piece of it, even this move that makes our functions more useful. It still leaves themselves contain they're not affecting global memory, it's still protected. This is still moving in the direction of functional programming.

[00:11:07]
All right, so let's take a pair programming break, where you're now going to start jumping into the closure challenges.