Well, yeah, you could do it here. And a lot of people end up doing that. The only downside to that is, well, you're setting the function so that it will be redeclared and redefined for every single instance of User. Now, instead, it's recommended to attach this to the prototype. That way, every single instance of User will share that method, rather than recreating it in memory. So you would then do this, User.prototype.changeEmailAddress to the new email. And then you could assign it here. Okay, so now you could create a User. I'll do myself, support at liricast.com. And then if we wanted to call the method, User.changeEmailAddress to foo at example.com.

Okay, so now you could create a User. I'll do myself, support at liricast.com. And then if we wanted to call the method, user.changeEmailAddress to foo at example.com. All right, so you create a constructor, you assign any attributes to it. For any methods that you want to share, you attach those to the prototype object. And then you can new it up very much like other languages. All right, so at this point, if I were to do console.log user, or in fact, let's do console.dir. If I load this page and give it a refresh, sure enough, we have our updated email address and the username. All right, cool. So yeah, this is kind of how we handled it in the ES5 days.

sure enough, we have our updated email address and the username. All right, cool. So yeah, this is kind of how we handled it in the ES5 days. But now with ES6, we basically have syntactic sugar, which more or less does something very much like this. Let's switch over. Class User. We have a method called changeEmail. So very much like the object notation, yeah, I can use this short method syntax. So we will have newEmail, and we will assign that. But now where do we declare the username and the email address? Well, just like other languages, like PHP, you do that in your constructor.

But now where do we declare the username and the email address? Well, just like other languages, like PHP, you do that in your constructor. username, email, and assign them. Now, I don't know about you, but I much prefer to see something like this. Maybe it's because I mostly work in the back end, and this is a lot more familiar to me. Either way, I think it's a big improvement. So once again, we could say $user equals a new instance of User. Jeffrey Way and support@lyricist.com. And then I can change my email address just like we did before.

Jeffrey Way and support at lyricist.com. And then I can change my email address just like we did before. All right, console.dir user. And if I switch back to Chrome, refresh, we're going to get the exact same thing. Now, like I said, as it turns out, the class syntax you see here, once again, is just syntactic sugar over the old way we used to handle it. So for example, this changeEmailAddress, behind the scenes, that's still being added to the prototype. I'll prove it to you. Back to Chrome.

I'll prove it to you. Back to Chrome. Notice proto. We take a look, and there's your changeEmail method. So if you ever hear anyone refer to this as sugar, the class syntax as sugar, yeah, that's what they're referring to. However, as it turns out, there's still so much more we can do with the syntax, and it really does save us a lot of code. For example, what about static methods? If you come from any other language like PHP, then you're very familiar with this.

For example, what about static methods? If you come from any other language like PHP, then you're very familiar with this. For example, maybe you like PHP's named constructors, and that allows you to do things like User::register, and then you pass in your information there. And that would be like saying $user equals new User, you pass in your information, and then maybe you call another method, right? Okay, well, we can do that exact same thing here. So at the top, I could say static, and then the name, register. Now, this method is only callable directly off of the User object.

So at the top, I could say static, and then the name, register. Now, this method is only callable directly off of the User object. Or in other words, I can't reference it within an instance method like this. I can only use it by saying $user->register. All right, so that means, yeah, I could do something like this, $user->register. And now if you want, we could return a new User, and we pass that information through. Okay, so let's get rid of this. And if we switch back to Chrome, refresh, there you go. Still get the same thing. Now, actually, a quick note on this,

Still get the same thing. Now, actually, a quick note on this, you've already learned about the rest and spread operators. So if you didn't want to duplicate the argument list, remember, they would always probably need to be in sync. So yeah, if you didn't want to do that, you could use the rest operator, args, and then the spread operator to pass them through. Now, if I come back and refresh, I'm still going to, once again, get the exact same thing. So quick recap on that, ...args means any arguments we pass in will be represented as an array.

So quick recap on that, dot dot dot args means any arguments we pass in will be represented as an array. So if I console.log args, refresh this, you get an array of all the arguments. Next, when we pass it through here, that's almost like call_user_func_array in php. So we're passing an array, but each of the items in that array will be converted to single arguments or values. Now, what else? We also have accessors. So setters and getters, basically. You could do something like getFoo and have that return anything on your instance you want.

So setters and getters, basically. You could do something like getFoo and have that return anything on your instance you want. Yeah, so there, let me give you some space. You could do $user->foo to access that value. So you can imagine using this even for something like computed values. That would be fine. So back to Chrome, refresh, and we get that value. And by the way, the exact same thing would be true for a setter or a mutator. Now, anything else? Well, how about this?

And once again, we'll just say alert using the alert strategy to log. You get the idea. Whatever mechanism you need to use there. All right, so does this make sense? I'm calling a log function. The log function expects some kind of strategy that responds to a handle method. So in this case, we're using like a one-off class here. Just like, by the way, anonymous classes in php. Exact same thing. So if I come back to Chrome, refresh, we get the alert.

they can even be passed through as function arguments. So in this case, yeah, maybe you have a log function. You could then pass an anonymous class to handle the logging strategy in this particular example. And then next, you learned about custom accessors. So just prefix get or set when you need to fetch some kind of value or computed value. And then finally, you learned about statics. Prefix the word static, and then you can access it directly off of the class without having to first create an instance of the class. Okay, that'll do it for this lesson.

without having to first create an instance of the class. Okay, that'll do it for this lesson.