Named arguments allow us to call a function or method, and then pass the argument based upon the parameter name, rather than the order it occurs. Here's an example. Let's say you have a class Invoice. We'll set up the constructor. Maybe every Invoice needs a quick description, the amount of the Invoice, the date the Invoice was prepared, and then maybe a boolean for whether or not it has been paid. Okay, let's go ahead and initialize those in the traditional way. And now, if I were to instantiate that Invoice, we might say customer installation, whatever it is.

And now, if I were to instantiate that Invoice, we might say customer installation, whatever it is. Maybe the total is $100.00, maybe it's right now, and then finally we'll set true to mark it as paid. Okay, so if I were to save that, var_dump, this is what you get, exactly what you'd expect. But now what often happens is you return to this code six months from now, you see this boolean reference or even the number here, and you think to yourself, I have no idea what that refers to. So you end up clicking through to the underlying class, and then you check in that way. Or maybe what you do is you create a needless temporary variable just to add a bit more.

So you end up clicking through to the underlying class, and then you check in that way. Or maybe what you do is you create a needless temporary variable just to add a bit more clarity. You're not going to use that variable, but when you come back six months later, you'll know immediately, oh, that's whether or not the invoice has been paid. And the same might be true for this. So as part of PHP 8, if you like, you can reach for named arguments or named parameters. Let's see what you think. I can now say the paid parameter is set to true. The date is now, the total is $100, and the description is that.

I can now say the paid parameter is set to true. The date is now, the total is $100, and the description is that. Okay, so now if I give it a run in PHP 8, it works just like it did before. But of course, in PHP 7 and below, it's going to blow up. Now what's nice is because we're using named parameters here, the order is irrelevant. So I could put the description down here, the paid at the beginning, it doesn't matter at all. So I give it a run and everything still works. Nothing blows up. But yeah, you can see in this case, it looks like PHPStorm does have a warning here.

Nothing blows up. But yeah, you can see in this case, it looks like PHPStorm does have a warning here. Named argument order does not match parameter order. So you don't have to do that, but it's a warning that you might want to sort it. But yeah, you can disable that if you want. It's not required. So give it a think. Do you like this approach? Do you see any downsides? It does solve that readability problem, which is why we created a meaningless temporary.

Do you see any downsides? It does solve that readability problem, which is why we created a meaningless temporary $variable in the first place. However, one thing to be cautious of and aware of is if you adopt named parameters, you are now coupling your code to the $variable or $parameter names themselves. For example, imagine this is coming from some package you use. And at some point, the maintainer is refactoring their code. And they think this $date here, it's not just the $date, it's more specifically the $chargeDate. So they go ahead and update this, like so.

date. So they go ahead and update this, like so. Well, with named parameters, this is now technically a breaking change. Think about it. The maintainer releases a patch release, you pull it in, but then you run your code or you run your tests, and everything blows up, unknown named parameter date. So this is what I mean when I say now, your code is coupled to the variable or parameter names themselves. You would have to keep this in sync. Or the maintainer would need to release a major version just to document the change.

You would have to keep this in sync. Or the maintainer would need to release a major version just to document the change variable name. So as it turns out, developers come out on both sides of this conversation. And you will need to decide for yourself or for your team, what makes the most sense. Now as a package maintainer, you can always just say, look, I'm not responsible for whether or not you use named parameters or not. So just keep in mind, I'm allowed to change a variable name without having to worry about your project blowing up. So enter at your own risk.

And then yet again, you probably want to put these on their own line. We run the code, and it's all still working as it did before. So what do you think?