For the first last thing, let's start with an easy concept. Let's talk a little bit about strict typing. You probably know that php allows us to type our function arguments and our return types. So you can have, for example, a function called ADD that takes two arguments and you can tell php that those two arguments should be integer or should be floats and that they should return an integer.

that those two arguments should be integer or should be floats and that they should return an integer or a float, and then php will ensure that happens. If you pass a different type, it is going to crash. The trick piece is that php also has something called type coercion. So if you have a function that takes an integer and you pass a numeric string, think about the string five. It is technically a string, but php will automatically convert that into an integer so

It is technically a string, but php will automatically convert that into an integer so that it can fit into the function. Usually that's fine, that's not going to be a problem, but sometimes php might do a type conversion that you would not like, and sometimes it's going to introduce some very tricky subtle bugs that are extremely hard to debug. So let's jump into the code

that are extremely hard to debug. So let's jump into the code and see what that is in practice. So here's our very simple example. We have a PaymentSchedule class that offers a calculatingInstallmentAmount method. It takes a totalAmount, the numberOfInstallments and gives back how much each installment would amount to. We also have a Task pretty straightforward. We're passing 1000 as the amount we're saying we want

We also have a task pretty straightforward. We're passing 1000 as the amount we're saying we want for installments, and then we expect the amount printInstallment to be 150. If we run this, it passes. Well, the first thing is we are not declaring what our types are meant to be. So we could say that this is 1000 and that is going to pass, but we could also say that this is full

and that is going to pass, but we could also say that this is full and our editor would not complain about it because this method takes anything as a parameter. But if we try to run this, it is going to fail, not because the type is invalid, but 'cause we can not divide a string by an integer. So the easiest thing we can do here is just type those two. We can say that you expect an integer as the totalAmount, an integer as the numberOfInstallments,

We can say that you expect an integer as the total amount, an integer as the number of installments, and we expect to return a float. If we go back to our test and rerun it, you can see that now php is giving us a type error. It is saying that the arguments would be an integer, but we're passing these strings, so let's revert this back to 1000. If we run this, it passes. Now here's the tricky part.

so let's revert this back to a thousand. If we run this, it passes. Now here's the tricky part. Let's go into the installments and say that we won four, but we're gonna pass a numeric string instead, even though our method expects an integer, this is going to pass and he passes and you may think, okay, that's fine. Four is still four, right? Even though it's a string, it's still the number four. But here's the problem. What if I pass 4.5? First of all, 4.5 is not a valid value.

But here's the problem. What if I pass 4.5? First of all, 4.5 is not a valid value for number of installments. You cannot have four and a half installments. But even then if it were, this number should be divided by 4.5, right? But if we run this, you're gonna notice that it is surpassing, although php unit is telling us there were some issues. That is because php is converting this into an integer.

although php unit is telling us there were some issues. That is because php is converting this into an integer and it is getting rid of the decimal. So even though sometimes the conversion might even be correct, it is not predictable and can add a lot of confusion. Here's how we get rid of this. We're gonna go into the top and we're gonna say declare(strict_types=1); What this is going to do is instruct php not

and we're gonna say declare(strict_types=1). What this is going to do is instruct php not to do any type coercion. So you can see that my editor is already complaining about this. We expect an integer and we're getting a string, and if we try to run this, we're gonna get a type error. We're expecting an integer, we're getting a string. So php is not converting those into an integer. One important thing is

So php is not converting those into an integer. One important thing is that we must always declare string types on the file. That's calling other methods or rather on the class. That's calling other methods type coercion always happens on the call side, not on the callee. So if I were to get rid of this here and you can see that my editor is going to stop complaining about the 4.5 and I were to add it on paymentSchedules,

to stop complaining about the 4.5 and I were to add it on payment schedules, you're gonna notice that this is still going to work. So payment schedule does not even know it is not receiving an actual intro. It thinks that it is 'cause php is converting that ahead of time. Let's add our declare(strict_types=1) here, let's get rid of this, and now we can be sure that this class is always going

One here, let's get rid of this, and now we can be sure that this class is always going to take integer. If I pass a string, it is going to fail. If I pass a float, it is going to fail. It will only accept an integer. strict_types is the kind of thing that takes very, very little effort to enable and brings a lot of value when it comes to predictability. If you're thinking of enabling strict_types across all files.

and brings a lot of value when it comes to predictability. If you're thinking of enabling strict types across all files in your project, just be careful. There are a couple of things that could happen. The first scenario is everything's okay, nothing changes. Your project works as you used to and that's great. The second scenario is some tasks start blowing up. Maybe because your application unknowingly expected those types to be juggled and now you've changed behavior.

expected those types of be juggled and now you've changed behavior. That kind of sucks. But if you have tasks, you can spot them and you can fix them. And the third scenario is behavior changes. Because now you're not juggling types, you don't have enough tasks to tell you that those problems are happening and things start breaking. So I'm not saying don't do it. I'm actually saying don't do it. Be careful.

So I'm not saying don't do it. I'm actually saying don't do it. Be careful. Do it on a profile basis. Go slow as you're working on a file, add some strict types if you wish to. And in time your entire project will at some point be covered by strict types. But I would not suggest doing it all at once. Just enabling and calling you yellow. Be a little bit more careful,

Just enabling and calling you yellow. Be a little bit more careful, do it a little bit more slowly. Your project survived all the time. Without strict types, it can wait a little bit. As usual, thank you for watching this lesson and I'll see you in the next one. Bye-bye.