without you having to extend the framework, or fork it, or contribute to the framework and change the behavior for everyone. Let me show you how this magic works. In our console command here, we can call any method on the Command class from inside the closure like so. So, for example, to print an info line, we call this info and provide a message. And to print an error line, we may call this error and provide a message. When Laravel invokes the closure, it will bind it to the scope of a closure Command class. This class extends Laravel's Command class, which means it has access to all its methods. That's why when we call this here inside the closure,

This class extends Laravel's Command class, which means it has access to all its methods. That's why when we call this here inside the closure, Laravel knows that by this, you mean the command object. That's magic too, but that's not what I want to show you. Let me call these methods, this correct and this wrong. And then we run the command. And here we can see the output of our method calls. Let's inspect this closure command that Laravel bounds our closure to. Then let's search for the info method. And here it styles our message as an info and prints it.

Then let's search for the info method. And here it styles our message as an info and prints it. Let's search for the error method. And here we go. It styles the message as an error and prints it. Now we search for the correct method. And we can't find it. How about the wrong method? And we can't find it either. Where does Laravel get these methods from? I will tell you.

Where does Laravel get these methods from? I will tell you. These are custom methods I injected into the Laravel command class. And the way I do that is by using macros. Let's head to the AppServiceProvider. And here you can see the two macros I registered. By registering a macro to the command class with the name correct, I made this method available on all objects of type Command. So when I call a method with a macro name, Laravel will inject this closure and give me the output.

So when I call a method with a macro name, Laravel will inject this closure and give me the output. Which in our case it prints a line with a custom style. You may have noticed that inside the closure of the macro, that this $variable is bound to the context of the command object as well. And that's why we have access to methods in this object. Now, defining too many macros in a service provider like this may not be the best idea. So to avoid that, let's define a class. I'll just define it in the same file for the sake of speed. So class AnswerValidator.

I'll just define it in the same file for the sake of speed. So class AnswerValidator. Then add a correct method. Return a closure from inside the method. And then move the call to this line from the macro to here. We will do the same thing for the wrong method. Change this line to print a wrong message instead. And then we delete the macros. And then we will call commandMixin. And provide an instance of our AnswerValidator class.

And then we will call mixin command. And provide an instance of our AnswerValidator class. Now when we run the code, it still works. Mixins allow us to define a group of macros inside a single class. All methods inside the class will be available to the object we are adding the mixin to. Notice that the methods must return a closure. Also notice that inside the closure, $this is bound to the object the mixin is added to. So what do you think? Should you use macros in your application code to extend the framework functionality? I personally use them all the time.

Should you use macros in your application code to extend the framework functionality? I personally use them all the time. But I also know that it confuses a lot of people when they are reading the code. And they get confused by where these methods are coming from. So if you are going to use macros, use them wisely and communicate with your team about them. That's it for this lesson and I will see you in the next one.