Original subtitles

There's one last little item I want to point out about our current deck implementation, if we scroll

down to the deck constructor, so here it is right here and find our double nested for loop.

Here it is right here.

We'll find the card constructor.

At present, we are passing in the rank as the first argument and the suit as the second.

Now, I want to show you a very easy way that we could introduce a kind of nasty bug to our program

if I were to swap the order in which I pass in the rank in the suit.

So now it's suit and rank.

I get absolutely no feedback telling me that I just made an error.

In fact, I can still run the program successfully.

But now I get some very weird output.

I see diamonds of diamonds of two and diamonds at three and so on.

So this is definitely a nasty little bug.

And I get no feedback from Darte telling me that there's any issue here whatsoever.

So in order to help you and I solve issues like this where we have some very specific of order of arguments

that are expected, Darte has a feature called named Parameters.

So rather than just passing in the suit or the rank as the first argument and the suit as the second,

we can name the parameters that get passed into this card constructor and then we can provide those

name parameters in any order that we wish.

So let's do a little refactor here and you'll get a better idea of what I mean.

I'm going to first start by adding a new line character in here like so and I'm going to put a new line

after rank as well.

OK, now here's the refractor, I'm going to say suit Kolan suit and rank, Colen rank.

Now we immediately see an air message, but we'll just ignore that for a moment, what we just did is

provided named parameters to the card constructor.

Now, the left hand side of each of these colon's is the name of the argument to the name of the parameter

that we're trying to provide to the constructor.

The fact that the variable name is suit on the right hand side is not relevant at all, the name of

the parameter and the actual value that we provide do not have to be identical.

So in other words, I could change suit right here to my suit and change that right there to my suit

as well.

And now this would be completely equivalent to what we had before, the name that we provide to the

parameter is not at all tied to the actual variable itself.

Now we'll go down to our cart constructor, where we're going to massage it a little bit and tell it

that it should expect to receive a named argument list, sit down at the bottom of the file.

I'm going to find my card class.

Here's my card constructor and then all we have to do to tell our card constructor that it should expect

some named arguments is add a set of curly braces around this rink and this dot suit like so.

So now, any time we create a new card, we're going to pass in.

A variable named suit and a variable with name of rank.

And then down inside this constructor.

The constructor is going to look and see that it's being provided a list of named arguments and it's

going to try to find in that list one argument named Reinke and one named suit at the.

It's then going to extract those arguments and assign them to the appropriate instance variables.

So now I should be able to run this code.

And I see it correctly, two of diamonds, three of diamonds, four of diamonds and so on.

So the benefit here is that by having these named parameters when we create our card is that we no longer

have to remember the order in which we have to pass these in.

I can freely rearrange this order as much as I please so I can put that rank first and then second,

I can run this and everything is still going to work the way I expect.

OK, so that's pretty much it, that's named arguments or name parameters in DART, so let's take a

quick pause right here and continue in the next section.