Module feature and Place holder feature #9
Conversation
|
I will take care of the conflicts |
- reduce the global surface - possibility to create 1 container per test case, then run them in parallel
- fix validate lifetime bug which cause flaky tests - fix "simple" examples
|
|
While resolving the conflicts, I reviewed the last commit and got some remarks "isBuilt" and "isSealed" is quite confusing in the last commit.I understand the idea that if the container validation was a success then it is useless to check validation over and over again for future services resolving. While it is true most of time, exception exist for users who don't follow our recommendation: RegisterLazyFunc(Scoped, func(ctx context.Context) (*A, context.Context) {
if (randomNumber is odd) {
b1, ctx = Get[*B1](ctx) //A (sometimes) depends on B1
return &A{b1}, ctx
} else {
b2, ctx = Get[*B2](ctx) //A (sometimes) depends on B2 => circular dependency here
return &A{b2}, ctx
}
})This guy ignores our recommendation. He put some small "if" in the resolver, making A sometimes depend on B1, sometimes depends on B2. The container's validation success, but he still not confident that his dependency graph is good. So he doesn't want to disable the runtime validation, but unfortunately it is automatically disabled with the isSealed boolean of this commit. Naming
While the enum Avoid repeating logicsthe following logics appeared multiple times if !isSealed && !DisableValidation it deserves to have a function func shouldValidate() bool {
return !isSealed && !DisableValidation
} |
|
hi @duongphuhiep |
|
thanks for your trust, I would gladly listen to your idea about "module" and help to maintain the project. as for v1, I will open a new discussion thread for various points I can think of |
The first commit add the Module feature
motivation:
The second commit add the Place Holder feature
This feature has the potential to become one of the most useful feature (or added value) of Ore.
Problem the feature will solve:
your certain Service depends on certain UserInfo (user name, user's role...), but you don't have them on registration time. Only after parsing the user request, connect to the database... that you will know the user's name, his role...
Because you cannot register a specific UserInfo directly so a common work around is to Register a UserInfoProvider instead.
As a result you have to make your Service depends on the UserInfoProvider while the real dependency is UserInfo.
A common implementation of the UserInfoProvider is to provide the UserInfo to the request context, so that it will be retreived later to create the Service => this common implementation repeat exactly what Ore is doing.
With the "place holder feature", you no longer need a UserInfoProvider "proxy". Your service depends directly to the UserInfo (as it should).
We can also think of this feature as eagerly registering an object but with Scoped life time similar to RegisterEagerSingleton
checkout the README for more info
Inspiration source:
other bug fix (second commit)