 about how we can write classes in JavaScript. So I think I just started writing proper JavaScript a few months ago. And then every time I want to make my own app, I realized that I want to write clean code because I want to look back at my code like six months from now and know what the hell it was. So I tried to read up on what's the right way to write stuff. And I realized that JavaScript is not a class-based language. It's actually a prototype-based language. But then it's expressive enough that you can actually write classes with it. So I researched on a topic, and I found it quite interesting. And so I decided that I wanted to give a lightning talk on this topic. So it's actually meant to be a lightning talk, and it shouldn't be that long. Anyway, so the introduction. So like I said, we want to write clean code. And one way to do that is to use inheritance so that we can reuse our code and we don't repeat ourselves. So dry beans don't repeat yourself. And we stay dry and not wet, which is write everything twice. So JavaScript is very expressive, and you can use it for many sort of programming paradigm. You can write a functional style. You can write a classical style, which I'm going to introduce or talk about today. So why did I talk about this? Like I said, when I first wrote app, I actually have no idea how to use class-based method in JavaScript. It's like I saw some snippets on Stack Overflow. I copy and paste. It seemed to work, but then somehow it broke. So I thought, OK, I'm going to sit down, read through what actually happens behind the under the hood, and do a summary of it. So what should we expect of classical-based languages, or class-based languages? We need to know how to define a class. When you define a class, you want to write constructor. Constructor is basically how you want to instantiate your class. And then you write methods, properties, and then you want to reuse your code for subsequent classes. So when you want to define a class, what you do is you make a function. So in JavaScript, functions are pretty much quite expressive. You can use it for a lot of things. When you use function, what you're actually doing, OK, when you write a definition function, like function vehicle, what you actually do is you make a function object, and you also make another object, which is the prototype of it, which has a constructor, which points back to your function object. So all my slides, you just look at the diagram. The diagram really speaks 1,000 words. You can forget why I write about the words. The words are for me. Diagrams are for you. So when you do function vehicle, that's what you are doing. So that's how you create a class. And then now we want to add a method. So in JavaScript, the prototypical way is to add it to the prototype so that all your other instances would have reference to that one function. So here, let's say I have a function called makesound. And I add it to the prototype. And what actually happens in the diagram is that in your prototype object, you add a new label called makesound, which refers to your function. So what happens when we create a new instance? All right, so yeah, I skip one step. Anyway, so once you have a class and you add a method, now what happens when we do new vehicle? So new vehicle is kind of like class-based language where you create a new instance. So in JavaScript, what happens is when you do new vehicle, you create a new object, which has the prototype that points to your function definition. So look at the first line. That's what happens when you define vehicle. And then when you do new vehicle, you create a new object where the prototype points to the prototype of the first vehicle. So now in new vehicle, you have the makesound because it has a reference to the makesound function. So that's how you do prototypical inheritance. So now we talk about constructor. So when you define function vehicle and then the body of that function, what are you actually doing? You're actually making a constructor. And then this basically refers to when you do new something, that new object you're creating is called this. So you can add properties to it. So look at a diagram and that's what's happening. So there are actually two ways to add properties to it. The first one is what we do in the constructor. The second one is what we do to the actual function object. So this was what we do in the constructor. And this is what happens if we do it in the function object. So the red color one is when we add a weight. So now we want to, so when I was trying to do this co-classical stuff, and then I search on Stack Overflow, there's a difference between object.create and then new. So then I was quite confused like, why is there two different things? So this is how I clarify it. So when you do new vehicle, what you're doing is you're running the constructor body. But when you do object.create, you're actually copying the function object. So copying the function object without calling the constructor. So if you look at vehicle, it has both the blue type and the red weight. When you do object.create, your new object only has the red weight without the blue type because. It's not fun. Really? So object.create doesn't copy anything. All it does is it gives you a new object whose prototype points to whatever you pass in. So object.create here, the vehicle in this case is not a prototype. It's actually a function. OK. I don't think that's going to work. So are you saying that the prototype actually points to a vehicle? The vehicle function. So in this case, what you've got is you have. So the prototype will work. See all these pointers that are pointing around? When you put an instance in JavaScript, when you access, for example, like the dot type property on your new vehicle, it will find it on the current object. But when you go to access make sound, it won't find it on the current object. So it then looks in the prototype chain. So when you end up finding that, when you do this object.create, you've got it's pointing at this function, which is just like, that's fine. So you won't be able to access make sound, but you will be able to access it all the way. What you should have done is probably a vehicle printer. Probably. OK. OK, I'll probably look at this again later. But yeah, I think, yeah, so like what you said, I think object.create takes the object and makes the prototype point to the. Just give you a new one. It's exactly like new, but it doesn't run a. The constructor. Right, OK. OK, ignore this slide then. OK, so now we've added a method, we've added a property. So now we want to, how do we do inheritance with it? So now I'm going to make a new car function, car class, which inherits from vehicle. And the way we do that is we change the prototype. So in this case, we can do car.prototype, we've got a new vehicle. So what we've done is we create a new function car, and then we get the prototype to point to a new vehicle. And then so now we ask the question whether car can find make sound. So like what team has said, you first, when you create a new car, you ask whether you have make sound in this prototype. So this prototype is a new vehicle, which does not. So it follows the prototype chain, which is now the dotted line. And it finds in the first prototype make sound, and therefore you can find make sound. So the last part, which goes back to the first slide where I said that when you make a new function, you're actually creating like a loop. So to complete a loop, we want to ask, what about, what should a constructor point to when you do car.prototype.constructor? Because when you first make vehicle, you do vehicle.prototype.constructor, and it gives you vehicle. So now you want to change the prototype of the car object to point to itself. So you can do one last step to kind of complete the loop, which you do car.prototype.constructor equal to car. I personally have not found a use for this constructor pointing to itself, because you probably want to do instance of looks at your prototypical chain, whereas this constructor kind of just gives you the body of your constructor if you need it. So I guess you can use it to determine whether it's a car or vehicle, but there's probably other better way. But this is just for completeness sake so that it looks nicer. So like I said, this is born out of like a self-research thing. So when doing my own research, I thought like some of the questions that I asked myself. So the first one is like, why do we define the function in the prototype rather than the constructor? And the reason for that is that when you run a constructor, if you define your function in it, which you can, because functions are first class objects in here, you're creating a new instance each time, so your memory might get clogged with repeated instance. And if your function is kind of you can reuse it, then you just put in a prototype so that you don't waste memory. And for properties because you don't want all your instance to share that same property. If that's the case, then fine, you can put in a prototype. But if that's not the case, then you want to put it in your constructor so that each instance has its own version of the properties. So then I decided to look at some of the type-based derivatives of JavaScript. So like first one that came out was like CoffeeScript. So on the left is what you would write in CoffeeScript. And then there's a transpiler which converts it into JavaScript. And then on the right is the JavaScript version. So we can see the pattern that we've looked at. So on the left, so it's all the same thing. I'm just defining an animal. Then I'm giving it a property called hypername. And then a function called describe. And then we see how it's done in how the transpiler converts it into JavaScript. And we can see that we do, in there you have a disk.describe. OK, look at animal.prototype.describe. That's defining a method. And then animal.hypername is describing the property. And then I look at TypeScript. It's the same thing. So this kind of gave me the confirmation that I'm somewhat on the right track. So when I was researching this, my friend was like, is this even useful? Because ES6 is coming up. And in ES6, you have a proper way of defining classes. So you don't have to do all this thing and you can actually write class animal or class vehicle. And they have a constructor function and do all things. So I would say that it's still useful to understand what's happening underneath. Because even in ES6, all your classes are still just synthetic sugar. So it's just what it does under the hood is converts it back to what we've seen just now. And then it runs it. So if you know what's happening under the hood, you can write more effective JavaScript because you know what's actually happening. And the language becomes much more expressive than if you restrict yourself to a class-based language. So to conclude, I've talked about how we can use JavaScript to support classes kind of. So kind of that's what I see though. There are actually other inheritance models. So one person that I like to watch this video is Douglas Cropford. And he said in one of his videos that he stopped using new and this. So I have not researched much on this subject, but I think that is quite interesting idea. JavaScript is really very expressive and we shouldn't limit ourselves to just classical methods. So I think the second point you can ignore for now. So that's my reference. And thanks. Any questions? Yes? Can you go back to like about four or five slides? To where you signed the prototype of the car to the door or something? Yeah. Just one more. So here there's one issue with this is that, yes, you set the prototype up correctly so that it's a vehicle. But the problem is that you have no control of whether the vehicle constructor is called. So often what you want to do or how it's called. So if you've got an inheritance chain and, for example, the thing needs to have, you need to supply arguments to your super class. You can't do it using this method. But there is a solution. All right, so you do a call. You do a call on the constructor of your. So that's any call constructed by you. So if you put a call, vehicle.call this, and then pass the arms in, actually it's probably a supplier so then you can have a variable number of arguments. In the car constructor, that will give you, that will call the vehicle constructor for you, which is nice, but people still already called new vehicle. And if new vehicle requires a. Right, I see what you mean. OK, so that's why you should do object.create. The prototype, right? So what you would do here is, object.create, vehicle.creditite. And also make sure you don't accidentally just do car.creditite equals vehicle.creditite. Because if you start adding methods to the cars.creditite, they'll also end up on the vehicles.creditite. So the reason why you create an object.create is the way I think about it is like making a read-only copy of the prototype, the object that you pass in. Because any new properties will go onto the new object. And any time you write to that thing, they go onto the new object. But whenever you read, if you haven't changed it or attached new properties to it, they'll go through to the parent prototype. Yeah, go ahead. So that program, what happens if you change the prototype to a vehicle after a heritage from the vehicle? Will cars still inherit the new properties that you might find on the property? So all the property bookup happens dynamically, like at runtime. So if you attach new properties to vehicles prototype and then try to access them from your car, that will work. It's fine. Everything, yeah. So it's time to get a copy, but it's not a copy at all. Is there a preference that the prototype of a car has to do with the prototype of a vehicle? Prototype? It's much easier to think of prototypes as like a form of delegation. So it's like you've got an object, and then it's like delegating lookups to something else. If you can't find it here, then look here. If you can't find it here, then you look here. That's pretty much how prototypes work. And so from runtime. Yes? Do you have a favorite use case for your human knowledge? Like maybe now you're just offering how this all works. When you go now, you can just like do something that maybe you throw it just like, but now it's like a rage. Well, OK. So the question is whether I have any use cases for this. Not a favorite use case. OK, so I think this just, OK, coming from, I came from a Java background. So in Java, you're a class-based language. And although someone did say that if you want to write Java, write Java, then write JavaScript. But like doing the transition phase, I find that JavaScript is very powerful because you can write everything on a browser. So you can literally write something and you know that it's going to run everywhere. Someone can just go to the browser and click on it. They don't need to go through like security. I mean, running Java applets on the web seems to be a pain for me. Now it's probably better, but it's still a pain. So coming from Java background, I thought that writing a classical or class-like style is more easy to reason about. And yeah, so I think that's the main use case, trying to really understand what's happening when you write certain code. So you don't get confused when you do, like when you assign something to a prototype and then you realize, why is this affecting all my particles? So let's say you're making a shooting game and then all your bullets are somewhat spring upwards or something just because you made it bounce off or something like that. So I think it's more of really understanding your language and knowing what weapons you have rather than like crafting the weapon to do something. Yeah. I think you can talk a bit about the bombing and private methods. OK, sure. OK, fine. So I guess I thought that this was going to be a lightning talk, so I tried to keep it very concise. So if we ask about what we expect, we probably can say we expect private and public properties. So if we define a vehicle class, we want it such that when you do vehicle dot something, I mean vehicle dot something is not accessible to the public. So you can't just do new vehicle dot, say, title. Title is a bad example, but new vehicle dot title. But you still want to have another function that is able to make use of the title. So one way to do that is to make use of closures in JavaScript. So let me think of where's the best place to introduce this. So let's say, OK, one way to do that is in the constructor. So in JavaScript, when your constructor returns, you can either return an object or not an object. If you don't return an object, it returns itself. So when you do function dot vehicle, we said that we created that two objects. So if you're in your constructor, you don't return another new object, that's what you get. But if you return a new object, then you're actually creating another object that points to that prototype. So in that case, in your function constructor, you can create a private variable, and then you return a new object which does not have any reference to that private variable. Probably can do a demo. If that's just in a file, and you put a function in the file, then you can access the function in the file. That's basically private. Know this? OK. So if I do a.private, it's going to throw an error. It's going to be undefined. But yet, I can do a.sayMe, which should give one. Oh, yeah, full, sorry, I bet. I can test this. So that's how you create a private variable. You probably try to avoid returning anything from a constructor. The main reason why is because you kind of, there is no, you actually step around the entire construction process by doing that. So that object that you return has no, it's not of type vehicle. Yeah, it doesn't have a prototype. OK. It's changing a lot of work, right? Yeah, exactly. You've literally just returned that old variable. All the magic disappears as soon as you return from a constructor. OK. But what you can do is, one thing that people often do is return a new instance of the constructor if the instance is not currently an instance of the current instance. Ah, think if you're going to say that. As in, this is how you get around, this is how you build APIs that can optionally use the new keyword. So on the first line you said, if bracket, this instance of this is equal to a variable here. Oh, right. If it's not that, return new vehicle with all of arguments, that gives you back a new thing. That's really the only case where you should be putting a return statement in a constructor. Otherwise, you can produce very confusing code when somebody is trying to instance off against your constructor, but the thing that you can do is actually an instance. OK. But that's private, yeah. I think Crockford puts this example on his website, and that's why a lot of people use this for, like, private variables. But I personally find it, like, I've put it in this style, but it's never really useful. It's really ugly. It's not adding stuff to prototype, of course, to the big. In that function, you can't access a private variable type. It gets really, really heavy. I used to do a lot of stuff in this panel. I avoided it. This is through the last six months. So what's your current programming style? I just want to release all variables that I don't want others to use. OK. That's why a lot of people stop working, or it doesn't work the way somebody wants it to work. They'll be very thankful that you understood what it is. Yeah, it does that so many times. Often, the thing that you try to hide things, you're like, oh, you can't touch my private. Yeah, but if you make it actually public, but you know, it probably shouldn't play with this, it means that you're going to be in the high school. All right, thanks.