[5.1] Make alias resolution recursive #13976
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If you have a service
foo
, which has an aliasbaz
, which itself has an aliasbat
, then trying to resolvebat
with theContainer
will fail.Now in practice that's not much of an issue, because you more commonly using
Application
which extendsContainer
, andApplication::make()
will try to resolve the alias first, before calling its parentmake()
method. So the scenario above is actually resolved.However there is still two cases where it will fail:
bap
forbat
for example. [1][1]: Not very common as you rarely need that many aliases.
[2]: If
foo
is declared in a deferred provider, when makingbat
, the abstract got will bebaz
, which may not be declared as a service provided by the deferred provider, resulting in a service not found.A simple fix would be to make the alias resolution recursive, not big changes required, no BC break AFAICS and no big (if any) performance impact either.