Prototype Chain

[00:00:00]
>> Will Sentance: This seems great, I'm happy. Who's happy with this design where I have my increment function right there on user one? If I'd done user two, increment function right there. My user 705 would have increment function right there. Can anybody think about what of our underlying goals might be being, like, very easy to reason about? I love it. I know exactly where my increment function is. I added it. Chris, what can you see as a problem here?

[00:00:27]
Efficiency, memory. Absolutely. Chris was so quick and so on it. Efficiency, what am I doing here, Chris? Making copies. Yeah, brand new copy of my increment function being added to every single one of these objects. If I had 100 of them, 100 copies of increment. If I had 100 functions, which often I will, because I want a decrement user score, I want to log them in, I want to log them out. I want to display them, I want to let them add a profile pic, I want to let them add a username, delete.

[00:00:58]
Every single one of those functions is going to have a brand new copy on every single object. Fab, because that means that we know exactly that they're there when we need them, but completely and utterly untenable because I cannot be wasting that much memory space with exactly the same function on every single one. Go ahead, Austin. A lot of duplicate code every time you're creating. A lot of duplicate saved functions every time I'm creating.

[00:01:29]
Go ahead, Michael. Uh, maintainability, you are kind of like not giving it any organization within the, within the function, within the creating of the object. I think that's really powerful as well, and we will see how that can play out later on, although to be fair, that sits a lot in the object-oriented hard parts where we go into the subclassing approach where we can really start to structure the associated functions.

[00:01:48]
But we'll see that here today as well. Problems: every time we create a new object, user object, we make space in our computer's memory for all our data and functionality. Now the data bit makes sense. I need to say that RE and 3 are different from J and 5, but the functionality is the same. Our functions are just copies. Best, simple and easy to reason about. Is there a better way? Does anyone think, um, I guess, does anyone have an idea, like, in theory, I've got a, all I want to be able to do is when JavaScript sees increment, it can run an increment function.

[00:02:27]
Can anyone think intuitively? Yeah, Joe, what could I do? Like if we were extending the class of users so that... Yeah, so that sounds like maybe there's some way. But let's be really, really simplistic. What could I do in a kind of very, I don't want to have lots of copies of my function, how many would I like to have? Chris. One. You could make a function that passes in. Well, that would be very sophisticated and we could certainly do it, but you're right, we just want to have one function and our dream would be that we wouldn't need to pass in a function reference, but instead, JavaScript would somehow know a place to go look up for user 1, user 2, user 403.

[00:03:18]
And when it sees .increment, it wouldn't see it, we wouldn't have it on our objects directly, but instead we would have, let's say, increment stored, let's say on a separate object with a name, I don't know, like store of functions or, you know, function store. And somehow, when JavaScript's interpreter hits user1.increment or user2.increment, it would look on user one and go, oh, no increment function, but it wouldn't panic.

[00:03:54]
Somehow it would know to go and find the increment function on here that I could run user2.increment, and despite not having increment on it, somehow it would know to go and find this increment function here. And we absolutely do have that feature. Can anyone guess what chain gives us that feature? Everyone together, the, yeah, well done, prototype chain, exactly. Exactly right. We can use the prototype chain.

[00:04:21]
Store the increment, it's so good when I, when I say the, when you all say the punchline and then it's, because sometimes, as we see, it doesn't. Using the prototype chain, store the increment function in just one object, have the interpreter, JavaScript, if it doesn't find the function on user one, not panic. Chris rightly said, there it is, but if it isn't there, for it not to panic, and instead look up to that object and find increment there.

[00:04:48]
And when it linked user, oh yeah, and then use it there, use it from that function store. We would need to link user one and function store in some way so that the interpreter, not finding increment on user one and user two, makes sure to check function store to see if it's there. How can we do that? Using the Object.create technique, rather than declaring our object new user with an empty object literal.

[00:05:22]
Instead, we're going to declare new user using the Object.create. Now we know that Object.create, when it runs, can anyone remember what it returns out from Object.create? It returns out. Joe, do you remember what it returns out? An object with anything in it? No. An empty object. Always an empty object. We can pass in another argument that will allow us to add properties to it, but an empty object.

[00:05:52]
The argument we pass in here, user function store, ain't going to get added to that new empty object. It's an empty object. It's an empty object. But it's going to have some sort of hidden bond to our user function store, an object full of functions that any object created using Object.create that makes that hidden bond is going to have access to.