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
{{ message }}
This repository has been archived by the owner on Dec 8, 2019. It is now read-only.
In other libraries there is a feature that is known as "named dependencies", that allows to differentiate dependencies not only by type, but also by a String.
I think It is not nessesary to restrict this to a String.
Any argument to Resolver.get(...) after the first one could specify a subtype to differentiate what should be returned.
This would require to change the interface in a way that could even allow any level of nesting.
In other libraries there is a feature that is known as "named dependencies", that allows to differentiate dependencies not only by type, but also by a String.
I think It is not nessesary to restrict this to a String.
Any argument to Resolver.get(...) after the first one could specify a subtype to differentiate what should be returned.
This would require to change the interface in a way that could even allow any level of nesting.
This would also allow to solve #1 in this way:
which could just return the currently mapped provider from the mapping for the second argument.
The text was updated successfully, but these errors were encountered: