Next that we have nullable types. Let me show you an example. Let's say we have a User, and I'll use a macro here to accept an age in the constructor, and then we'll have a little getter here that will return the age. All right, so pretty, pretty common and standard stuff. So that means if I were to say new up a User who is 31 and grab their age, if we were to var_dump that and view it with PHP 7.1, sure enough we grab the age. Big whoop. Now you may know that PHP 7.0 introduced new scalar types and return types. Entirely optional, you don't have to use these at all if you don't want to. But if it's your thing, yeah, you could be explicit that this returns an integer. We use the colon and then the type, whether it be string or an object or an array or a boolean or an integer, right? So if we

explicit that this returns an integer. We use the colon and then the type, whether it be string or an object or an array or a Boolean or an integer, right? So if we run this again, nothing's changed here. This will work in php 7.0 as well. And that means if we were to change this to something else, like a string or an array, an error is going to be thrown. It must be an integer, but a string was returned. Okay, but there is one scenario if you are using this approach where often you will return the value, in this case the person's age, or sometimes null if the value hasn't been set. So imagine we give it null or for whatever reason age just hasn't been assigned to. Maybe something even as simple as this. Let's just get rid of the constructor. All right, so now age is null, but there will

just hasn't been assigned to. Maybe something even as simple as this. Let's just get rid of the constructor. All right, so now age is null, but there will be situations where that's entirely fine. You don't want things to blow up if that's the case. So if we were to run it now, though, we still get that error because it's expecting an integer, but we're returning null. So yeah, it blows up. Okay, so new in 7.1 is nullable types, and this can be applied to your type hints as well as your return types. Just precede it with a question mark. So let's run that, but you know what? I thought I disabled that. It must be a different package. Ah, phpCodingStandard. Okay, let's open it back up, and that fixes it. So yeah, let's run it. We new up a User, we fetch the age, age is set to null, but

package. Ah, php CodingStandard. Okay, let's open it back up, and that fixes it. So yeah, let's run it. We new up a User, we fetch the age, age is set to null, but because we specified that the return type must be an integer or nullable, nothing will fail. We run it, and sure enough, we do get null. So again, without it, it fails, but with it, we're saying return an integer or null. So that's an option if you like it. Or, you know what? Just don't do return types, and now everything's still going to work. I know it sounds crazy, but embracing PHP's dynamic nature might be a good thing. Let me show you one other example. So we have return types, but yeah, this also applies to your type ints. So maybe we have like a subscribe method, and as an argument to it, you can provide a

have return types, but yeah, this also applies to your type ints. So maybe we have like a subscribe method, and as an argument to it, you can provide a callback function, right? So maybe you do something like new User subscribe, and then once it's done with that, you want to respond in some way. We'll just say respond here. Okay, so we could say trigger the callback, and then I will simulate subscribing with a var_dump. Okay, so let's run it, and sure enough, we hit the logic, and then we hit the callback function. Now, in this case, we are assuming that you are giving us a function. But yeah, I mean, it's possible you could give it an array or a string, and once again, everything's going to blow up. So if you want to be more strict about this, you could add the callable

you could give it an array or a string, and once again, everything's going to blow up. So if you want to be more strict about this, you could add the callable type int. Whatever you give us, it just needs to be something that we can call. So now, in this case, it's going to fail because an array is not callable. But again, if we give it a function, then of course nothing's going to happen here. Okay, nothing's going to fail. All right, so that's fine, but yeah, maybe the callback should be optional entirely, and we decided that this should be valid, or maybe once again, the callback is something you have on your object, and again, that could actually equate to null. Any of those should be fine in our book. But right now, because we've set the callable type int, again, this is going to

again, that could actually equate to null. Any of those should be fine in our book. But right now, because we've set the callable type int, again, this is going to blow up if we run it. Must be callable, but you gave us null. So if we were to prefix it again with the question mark, now we're saying callback should either be callable or null. So when you see this, yeah, just think or null. Okay, so if we do give it null, we're gonna have to check for it here. Something like this. All right, let's try it, and nothing fails. But if we give it an array, it'll fail, as we would expect. If you give it a string, of course it's going to fail. And again, if you give it a callable function, it will not fail. Finally though, let's make sure it works if you pass nothing to it. We run it. Ah, it fails. So this is an