You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Proposal inspired by PHP-DI. Typically if you want to resolve a specific instance of an object where multiple [named] instances can be resolved, you'd want to do something like this, or write a custom Provider to handle the mapping.
class MyController
{
protectedGuard$guard;
// create as propertypublicfunction__construct()
{
$this->guard = Auth::guard('web');
}
// or create in called methodpublicfunctionindex()
{
$guard = Auth::guard('web');
}
}
class AuthProvider
{
publicfunctionregister()
{
$this->app
->when(MyController::class)
->needs(Guard::class)
->give(function () {
return Auth::guard('web');
});
}
}
My proposal is in two parts:
Since bind (and singleton, scoped, instance, etc.) is in most (?) cases used on some method (be it a named method or __construct), this would be facilitated by adding an instance of ReflectionParameter to the callback to resolve the instance. If there are cases where bind (and similar) do not refer to methods, perhaps introduce a method called resolvingParameter (name not important) which optionally returns an override (demonstrated below), using the default resolution method as a fallback.
Create Attributes to aid the Service Container in resolving specific instances:
A general Attribute Inject (name not important) for referring to a named Container entry
More specific Attributes for resolution of specific entries, for example GuardName (or similar) to resolve a specific Guard.
Here's an example for one of the specific instances, specifically GuardName - to use the current workflow of the AuthManager behaving as its own sort of container.
If you wanted to move away from it in the future, you could perhaps add Guards to the Container with the naming convention auth.guards.$name and add a method to the GuardName Attribute to get the formatted Container entry name, and then just use Inject.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Proposal inspired by PHP-DI. Typically if you want to resolve a specific instance of an object where multiple [named] instances can be resolved, you'd want to do something like this, or write a custom Provider to handle the mapping.
My proposal is in two parts:
Since
bind
(andsingleton
,scoped
,instance
, etc.) is in most (?) cases used on some method (be it a named method or__construct
), this would be facilitated by adding an instance ofReflectionParameter
to the callback to resolve the instance. If there are cases wherebind
(and similar) do not refer to methods, perhaps introduce a method calledresolvingParameter
(name not important) which optionally returns an override (demonstrated below), using the default resolution method as a fallback.Create Attributes to aid the Service Container in resolving specific instances:
Inject
(name not important) for referring to a named Container entryGuardName
(or similar) to resolve a specific Guard.Here's an example for one of the specific instances, specifically
GuardName
- to use the current workflow of theAuthManager
behaving as its own sort of container.If you wanted to move away from it in the future, you could perhaps add Guards to the Container with the naming convention
auth.guards.$name
and add a method to theGuardName
Attribute to get the formatted Container entry name, and then just useInject
.Beta Was this translation helpful? Give feedback.
All reactions