Allow providing types that depend on decorated types from child modules #325
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## master #325 +/- ##
=======================================
Coverage 98.16% 98.17%
=======================================
Files 21 21
Lines 1419 1423 +4
=======================================
+ Hits 1393 1397 +4
Misses 16 16
Partials 10 10
Continue to review full report at Codecov.
|
sywhang
changed the title
abhinav
reviewed
Feb 25, 2022
abhinav
approved these changes
Feb 25, 2022
sywhang
added a commit
to uber-go/fx
that referenced
this pull request
Feb 25, 2022
This modifies a test that was added in a previous commit which highlights a problematic transitive decoration of a parent-module provided-type. Specifically, consider the following case: Parent Module provides type A, and type B which depends on type A. Child Module decorates type A and invokes something that depends on type B. In such case, the invoked function in child Module should not see a version of type B created with a decorated type A. This is because the constructor for the type B lives outside the scope of the decoration. The decoration can only affect child Scope's providers, and should not affect parent-provided constructor directly. This test case is not compliant with such case, so it should be modified. This also pins Dig dependency to latest commit of Dig's master branch to take in the fix made in uber-go/dig#325.
luoboton
added a commit
to luoboton/fx
that referenced
this pull request
Aug 24, 2022
This modifies a test that was added in a previous commit which highlights a problematic transitive decoration of a parent-module provided-type. Specifically, consider the following case: Parent Module provides type A, and type B which depends on type A. Child Module decorates type A and invokes something that depends on type B. In such case, the invoked function in child Module should not see a version of type B created with a decorated type A. This is because the constructor for the type B lives outside the scope of the decoration. The decoration can only affect child Scope's providers, and should not affect parent-provided constructor directly. This test case is not compliant with such case, so it should be modified. This also pins Dig dependency to latest commit of Dig's master branch to take in the fix made in uber-go/dig#325.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This fixes the case where a function that's Invoked depends on a type that's decorated.
Specifically, if a type has a decorator in a child Scope, and there's another exported constructor consuming that type within the same Scope, and a function is invoked outside of that Scope, we still should see the decorated type.
Implementation-wise, this means that the constructors should know which Scope it was originally provided to, and invoke it from that Scope if and only if that Scope has a more "specific" Scope than the Scope it was invoked from. To make this comparison of "specific-ness" of the Scopes cheap, a new field was added to Scope to keep track of its distance from the root Container. A Scope with higher degree is the more "specific" Scope than one with a lower degree.