Next step is constructor property promotion. Let's say you have a class that represents a Signup. And to signup, we need the User, who is registering, and then also the Plan that they are registering for. So we create the fields, we set up the constructor, we accept the args, and then we assign it within the constructor body. And yeah, for every single class that accepts a dependency, you will follow this very pattern. So notice, for every field, we have to reference that variableName four times just to instantiate the class.

So notice, for every field, we have to reference that variable name four times just to instantiate the class. One, two, three, four. For every single field, so same thing for plan. One, two, three, four. It's messy. And then further, well, we have to set up the User class, and a User has a name. So let's go ahead and do that. And then we need a plan as well.

So let's go ahead and do that. And then we need a plan as well. I'm just going to reuse this. A plan has a name. And this is what we end up with. All right, so if we were to set this up, we'll instantiate our User, maybe JohnDoe, and then we'll create a Plan. How about monthly? And then finally, let's give us some room. We'll run our signup like so.

And then finally, let's give us some room. We'll run our signup like so. And then maybe you'll have something like signup, execute, or handle. And you get the idea. I'm just going to var_dump it. And if we give it a run, there you go. Now, of course, this is going to work all the way back to php 5. Nothing overly new here. But again, what is new is this concept of constructor property promotion. So here's the basic idea.

But again, what is new is this concept of constructor property promotion. So here's the basic idea. php can figure out what you're trying to do here. So if we give it a little bit more information, such as protected $name, as you can see here with PhpStorm, PHP 8 can do the rest. It can figure out, okay, you probably want to assign the variable and you want to create the field. So let's just do that for them automatically. That means we can get rid of this as well as this. And if I give it a run, we get the exact same thing.

That means we can get rid of this as well as this. And if I give it a run, we get the exact same thing. It just cleans it up a little. Let's do the same thing here as well. Protected, and then get rid of that. And then, of course, in phpStorm, if I option return, I can automatically remove that, an exact same thing. Now, on top of that, you can also declare the type in the process. So whether you want it to be generic or mixed, or if you want to be explicit that you expect a string,

So whether you want it to be generic or mixed, or if you want to be explicit that you expect a string, you can allow for that. You can even set defaults. So maybe the default plain name is monthly. So if we were to override it, of course, that will take effect, as you see here. But if we don't provide anything at all, it will correctly assign that default, as you see there. Kind of cool.

Declare the visibility, like so. And now I can get rid of all of that and all of that. And now notice your lines will get a little long, so you will likely get into the habit of this approach here, where each field gets its own line. Now, a couple caveats here. Well, actually, first, that's going to work just like it did before, but if we run it with php 7, of course it blows up. But yeah, a couple caveats to be aware of. You can set defaults, as we did up here,

But yeah, a couple caveats to be aware of. You can set defaults, as we did up here, but they're limited to primitives, so you can't provide any expression there. If you do need to perform extra validation or checks, you could do that in the constructor body, which means you can mix and match. If for whatever reason you're going to promote the User, but the plan requires its own logic, then you could do things like this.