Prototype Lookup

[00:00:00]
>> Will Sentance: Here's how we're gonna important checks. So we're gonna do it over here. Does our paidUser1 have access to its new or the functionality that's specific to a paid user? Let's have a look. Let's have a look. Elliot, you're up man. paidUser1.increaseBalance(), give me the lookup journey of JavaScript.

[00:00:27]
I'm gonna go on this side and kind of crouch down so you can see. So paidUser1, where do we look for it?
>> Elliot: So we'll look to the right.
>> Will Sentance: Well, we look for paidUser1 in global memory.
>> Elliot: And if it doesn't find it there
>> Will Sentance: Doesn't find what?

[00:00:40]
>> Elliot: The increase.
>> Will Sentance: Doesn't find increased balance method is not there. You've got name, score, account, balance. Don't see any increased balance method. We wouldn't want to, would we, because it means it would be a copy on user one, paidUser1, and then another copy on paidUser2, and another copy on paidUser3.

[00:00:54]
We don't want that. We want to have a single place. How do we get to that single place, Elliott?
>> Elliot: Through proto?
>> Will Sentance: Through proto. Up to
>> Elliot: Paid user functions.
>> Will Sentance: Do we find increased balance there?
>> Elliot: Yes.
>> Will Sentance: We do. We grab it. We execute it.

[00:01:08]
Fantastic. By the way, would user one have access to paid user functions? User one dot increase balance. Is it on user one? No. Looking proto. User functions. Is there increased balance there? No, because we don't want our user one to have a increased balance functionality, that'd make no sense.

[00:01:27]
So we kind of parcelled off functions. We get to choose which ones we want and pass them, not pass them down but have them available. But also have objects be generated at a level in that chain where they don't get access to things further down. Very nice, it's very very nice.

[00:01:41]
Okay. This is the prototype for design of a language. It's not classical OP. It's a prototypal language structure, which is I think very interesting. Okay. But now let's check whether you can still give paidUser1 access to that sayName function that is definitely not on its set of functions.

[00:02:03]
Let's go through the journey. Seth, give me the lookup journey.
>> Seth: PaidUser1 sayName is gonna look in the paidUser1 in global memory. It's not gonna find it.
>> Will Sentance: One second, it's not gonna find it. Yep.
>> Seth: It's going to freak out briefly and then look in proto.
>> Will Sentance: Where it's also-

[00:02:20]
>> Seth: Not gonna find it. And then it's gonna look in that proto, where it will find it.
>> Will Sentance: Where it will find it and execute it. Very nice Seth, excellent. All right, folk. That's, this is solution two, done. This is the most fine grain, this is the senior dev question, tell me how subclassing works under the hood, because this is it.

[00:02:43]
Now, we are going to mask this with a new keyword implementation that still requires, honestly, a little bit too much work to do in subclassing. Which is why it was reasonable for solution four to emerge as the new standard, where this whole approach is handled in a cleaner fashion through classes and through the extends and the super keywords.

[00:03:05]
And that's what we will see in a moment.