Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design and Implement context injection #85

Open
Voiteh opened this issue Jul 13, 2020 · 1 comment
Open

Design and Implement context injection #85

Voiteh opened this issue Jul 13, 2020 · 1 comment
Assignees
Labels
API Change Change to the API Enhancement New feature or request Priority High High priority issue

Comments

@Voiteh
Copy link
Owner

Voiteh commented Jul 13, 2020

Context should be an object used to retrieve dynamic deps like http request / response during deps resolution

shared Result inject(Injectable injectable, Object|Destroyable? context =null)
@Voiteh Voiteh self-assigned this Jul 27, 2020
@Voiteh Voiteh added API Change Change to the API Enhancement New feature or request Priority High High priority issue labels Jul 27, 2020
Voiteh added a commit that referenced this issue Jul 29, 2020
Voiteh added a commit that referenced this issue Aug 11, 2020
@Voiteh
Copy link
Owner Author

Voiteh commented Aug 17, 2020

Whenever injecting contextual parameter (not as dependency but directly) and types do not match exactly context-> declaration of given parameter, there is mismatch with dependency as parameter. In both cases Dependency.ResolutionError is thrown but in case of Injection parameter resolution message indicates that there were no problems with finding a dependency for resolution but matching the type. We should be consequent in that.

Possible sollution:

  1. Change way ContextualDependency works so before injecting value the Dependency must be found in tree.
    This resolution has it's drawbacks {Integer*} parameter is not exactly {1,2,3} it is clumsy for usage.

  2. Change way of finding given ParameterDependency in tree. Currently it is exact type match and then exact name match. We need ancestral match including interfaces
    a) We could first match to the name and then to type. This may increase lookup time as we need to iterate over all dependency declaration types -> get it's flat representation -> check if given type is contained. This resolution has problems with type parameters as they do not match always (espacially in case of contextual injection).
    b) We could create also second lookup tree that does interation when first fails. Still this resolutins also fails with type parameters in some cases.

  3. We could wrap ParameterDependency in ContextualDependency always even if resolved from tree. This will create inconsistency with rest of ParameterDependency

It seems that 2b is best option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Change Change to the API Enhancement New feature or request Priority High High priority issue
Projects
None yet
Development

No branches or pull requests

1 participant