About

This PR introduces a new version of LEC package with code niceties and new features.

Instead of relying on the naming conventions, we can now explicitly define the classes we want to forward, and much to say, we can now chain it. 🔥

How it works?

We can enable the forwarding and define which class to assign in case of missing methods or properties in the base class.

Define the forwarding:

Forwarding::enable()
    ->from(UserService::class)
    ->to(UserRepository::class)
    ->from(UserRepository::class)
    ->to(UserModel::class);

Make a proxy:

$proxy = call(UserService::class);

Call an existing method:

$proxy->existingMethod();

// Returns result from the `UserService::class`

Call a non-existing method:

$proxy->nonExistingMethod();

// Returns result from the `UserRepository::class`, because of forwarding defined above.

Call a non-existing method, but that doesn't exist also in UserRepository::class:

$proxy->nonExistingInRepositoryMethod();

// Returns result from the `UserModel::class`, because of chained forwarding.

So, why?

• In the first call, we received the result from UserService, because the method exists and it is expected.
• In the next call, the proxy managed to replace the internal call instance with UserRepository, because of the forwarding defined before.
• In the final call, the proxy swapped the internal instance to UserModel, because the method also missing in UserRepository (previous instance).

Use cases?

Still, I'm too lazy to think where to put a query. I may do that in the model, but then move it to the service if additional logic arrives. Then all calls stay untouched. I can manage forwardings at any time and without relying on naming conventions. Separation of concerns matters. 🙂

Caveats

Always take attention to which call instance you are working currently when calling methods, accessing, or assigning properties. If some of them don't exist, the proxy will swap an instance and you'll lose the internal state. I'm thinking about storing a previous instance or warning a developer in such a case, we'll see if it fits reality.

Hey,

I am using PHP 8.0.11 and Laravel v8.62.0.

After installing this package I changed my AppServiceProvider from:

$this->app->bind(
    ServerOrderInterface::class,
    FakeServerOrderService::class
);

to:

bind(ServerOrderInterface::class)->to(FakeServerOrderService::class);

And basically everything broke with:

Illuminate\Contracts\Container\BindingResolutionException 

Target [MichaelRubel\EnhancedContainer\Bind] is not instantiable.

About

We decided to drop support of syntax sugar in this package and scope more on important features: method binding, forwarding, and additional methods in the container.

These changes will ship as a major update.

About

Adds remember method allowing to resolve or execute the callback & bind results to the service container.

app()->remember('key', fn () => 'result');

About

This method will help us ensure our code will be executed if container resolution fails. This way we can bind stuff to the container "on-the-fly" even if it wasn't bound previously, or do something else.

For example:

app()->makeOr('company', function ($app) {
    $company = Company::firstWhere('uuid', request()->segment(1));

    $app->scoped('company', fn () => $company);

    return $company;
});

If we're resolving the service with parameters, we can do this:

app()->makeOr(Service::class, ['dependency' => $dependency], function ($app) {
    //
});

There are a lot more use cases though. Optionally, it would have been binding results of executed queries to the container to avoid query duplication in the scope of the request lifecycle, if someone doesn't want to deal with the cache/invalidation issues, etc.

Additionally, original Container tests were added. 🧪

About

• Added ability to set the previous instance in the CallProxy
• Added ability to disable forwarding on proxy level (isolated from the global scope)

B/C breaks

• Changed the type of $previous property from string to ?object.
• Changed the method visibility in the InteractsWithContainer trait from public to protected to avoid autocomplete in IDE for these methods as they were meant only for internal purposes.

Introduction

Laravel Pint is an opinionated PHP code style fixer for minimalists. Pint is built on top of PHP-CS-Fixer and makes it simple to ensure that your code style stays clean and consistent.

Topic

This PR adds the ability to resolve contextual bindings in any available class method based on the third parameter passed to the proxy.

singleton(BoilerplateInterface::class, BoilerplateService::class);

// defines the implementation globally

bind(BoilerplateInterface::class)
    ->contextual(TestService::class)
    ->for(BoilerplateServiceResolvesContextualInMethod::class);

// defines contextual implementation

In BoilerplateServiceResolvesContextualInMethod class:

call(BoilerplateInterface::class, [], static::class);

// static class identifies the context
// returns contextual implementation (TestService::class)

call(BoilerplateInterface::class);

// in the same class
// returns global implementation (BoilerplateService::class)

Additional:

• newgetInternal method to get proxy's internal properties.

call(BoilerplateInterface::class)->getInternal('instance');

B/C

• getInternal method is considered as breaking if someone used the same method before this addition.