Support Mixin's with constructor arguments

[itsDavidSQ]

When defining a macro we can make use of dependencies by passing them to the closure's context via the use keyword. For example, we could define the following macro in a Service Provider and it would work with no issues:

When creating a macro, we can pass any dependencies that may be needed by using the use keyword when defining the closure. For example, we could define the following macro in a Service Provider and it would work:

$apiVersionResolver = $this->app->get(ApiVersionResolver::class);

Request::macro('apiVersion', function () use ($apiVersionResolver): string {
    return $apiVersionResolver->resolve($this);
});

However, there was no way to achieve the same result using a mixin, as trying to do so resulted in an exception:

ArgumentCountError: Too few arguments to function App\Http\RequestMixin::__construct(), 0 passed and exactly 1 expected

This PR excludes the constructor method from mixin objects, allowing us to specify constructor arguments, which can be used within the macro methods.

Once merged, the following will work as expected:

class RequestMixin
{
    public function __construct(
        private readonly ApiVersionResolver $apiVersionResolver
    ) {
    }

    public function apiVersion(): \Closure
    {
        $apiVersionResolver = $this->apiVersionResolver;

        return function () use ($apiVersionResolver): string {
            return $apiVersionResolver->resolve($this);
        };
    }
}

// In a Service Provider:
$apiVersionResolver = $this->app->get(ApiVersionResolver::class);
Request::mixin(new RequestMixin($apiVersionResolver));

[henzeb]

same can be achieved with resolve() helper.

[itsDavidSQ]

That's right, but I feel having explicit dependencies makes it easier to reason about.

[rodrigopedra]

One could argue mixin classes shouldn't have state, as every method should return a closure that will be bound to the extended object.

But considering a class __constructor can be public or protected, which are the filters applied to get the methods being mixed up, I guess filtering the constructor out makes sense.

When mixing up the methods, each method is invoked to get back the closure to be mixed as a macro. So calling an object's constructor again makes no sense.

I would take a step further and also filter out destructors:

public static function mixin($mixin, $replace = true)
{
    $methods = (new ReflectionClass($mixin))->getMethods(
        ReflectionMethod::IS_PUBLIC | ReflectionMethod::IS_PROTECTED
    );

    foreach ($methods as $method) {
        if ($method->isConstructor() || $method->isDestructor()) {
            continue;
        }

        if ($replace || ! static::hasMacro($method->name)) {
            static::macro($method->name, $method->invoke($mixin));
        }
    }
}

[taylorotwell]

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!