Discussing DryIoc's approach on parameters of Func-wrappers

[Yeah69]

Hi,

Maybe a bit of context. I am currently working on an own compile-time DI container based on Source Generators. It's still private, but I'm already working on the finishing touches (validation, error handling, documentation, and so on).

Even though I don't have much practical experience with DryIoc, I had a lot of interest for it. Especially because it does a lot of things differently compared to Autofac which I'm most familiar with. As you know, one of those differences are the semantics of Func-wrapper parameters. For my DI container I chose to implement it very similar to the approach in DryIoc (with some differences which shouldn't matter for this discussion). Actually, it made even things easier, as the resolution is done recursively and that way I was able to just pass a collection of overrides down the resolution tree without much considerations of when to reset the overrides.

I'm thinking it through a lot. There is one caveat that is bothering me: while the Autofac approach has only one use case, the DryIoc approach has two. These are:

1. resupplying instances for "missing" registrations for the direct instance returned by the Func (DryIoc & Autofac)
2. overriding registered types for the whole resolution tree starting the instance returned by the Func (DryIoc only)
   (That is a simplification for the sake of my argument, because Autofac does override as well if the type of the instance is registered. I'm aware of that.)

While the DryIoc approach is handy and powerful, I could imagine that it could also make things like backtracking why where which instance was injected more difficult, because the configuration of container might - depending of the use of such overrides - play a far less role.

I might be overthinking here. What is your opinion on that matter?
Can you tell me about your experiences?
And maybe about the feedback that your user give?
If you would start from scratch - with everything you know now - would you still chose the same approach? If not can you summarize what you would do differently?

[dadhi]

@Yeah69 Hi here.

I could imagine that it could also make things like backtracking why where which instance was injected more difficult, because the configuration of container might - depending of the use of such overrides - play a far less role

I did not understand this part about backtracking.

Generally, the main cons of using Func<...> for overrides is inability to specify precise condition of matching dependency except for its Type. I like the Autofac approach with Typed and Named parameters here. Or rather, you need such an additional approach to the Func<....> feature.

DryIoc supports passing object array args to Resolve as the overrides - internally it piggies back on the same Func<..> support by wrapping the passed args each into Expression.Constant instead of Expression.Parameter (as for Func). Here is the issue #222.

I am thinking of extending this feature. In addition to the plain object arg matched by its GetType() I may add tiny specification wrappers, e.g. Arg.Of<TArg>(argInstance) or Arg.Of(name, argInstance), etc.

Open for questions, discussion and ideas.

Btw, I am genuinely interested in your approach with Source Generators, and whether you've considered StrongInject or something else? I know, there is much more SD based DI nowadays.

Currently, I am working on ergonomics and usability of mine compile-time DryIoc part, which was here for a while. But still keeping the t4 (mono/t4) approach, so prove me wrong :-) Today T4 as a dotnet CLI tool has a much more pleasant UX. The bad part is always the NuGet publishing story... so will see.

[Yeah69]

I did not understand this part about backtracking.

Please take the following snippet as an example:
https://github.com/Yeah69/DryIoc.Playground/blob/main/DryIoc.Playground/Case2.cs
It's very simplified, but imagine the code base to be much bigger and a lot of classes similar to Dependency and a lot of dependencies between Dependency and InnerDependency. Now, if you've got the container setup and the application ready to run, then you put a breakpoint at the getter of Test0 of InnerDependency which value would you get and why? In this example it is easy to tell, because it is minimal, but I could imagine that it could become trickier in more complex situations. That's what I meant with backtracking. Upon hitting that breakpoint how easy can you understand where the value originates from. Is it the container-configuration or one of the Func<…>s further above the resolution tree.

This isn't meant as an argument against such an approach. In my container you can reconfigure on per-scope basis which makes matters of such "backtracking" even worse, I guess. I am just trying to get features as powerful as possible ("power to the people" :)) and still make any point in runtime as comprehensible as possible.

Generally, the main cons of using Func<...> for overrides is inability to specify precise condition of matching dependency except for its Type. I like the Autofac approach with Typed and Named parameters here. Or rather, you need such an additional approach to the Func<....> feature.

Yes. I have a solution to this. In my container the user can specify function like DIE_ConstrParam_Dependency ("DIE" is the abbreviation of the project's name):

internal class Dependency
{
    public int Number { get; }

    internal Dependency(int number) => Number = number;
}

internal class OtherDependency
{
    public int Number => 69;
}

[CreateFunction(typeof(Dependency), "Create")]
internal partial class Container
{
    [CustomConstructorParameterChoice(typeof(Dependency))]
    private void DIE_ConstrParam_Dependency(OtherDependency otherDependency, out int number) => number = otherDependency.Number;
}

(This is the first public sneak peek :))
When the container needs to generate a resolution of Dependency it'll look up whether there is such a function, then it'll match the out-parameters to the constructor parameters of Dependency by type and by name. You can also let the container inject dependencies like OtherDependency into the function if you would like to have the out values be dependent on other dependencies. You can match any number of constructor parameters by adding further out-parameters to the function.

Btw, I am genuinely interested in your approach with Source Generators, and whether you've considered StrongInject or something else? I know, there is much more SD based DI nowadays.

Would you even be interested in reviewing the first release? But reviews will probably only make sense when I've finished the documentation or else it would cost too much of the reviewer's time.

Yes, I know of StrongInject. When considering all SourceGenerator-based DI-containers that I've looked into, it is the one which I like the most. I still got motivated to create my own DI-container, because of two points:

• It misses conveniences. From my experience code bases which use Dependency Inversion Principle have most of their interfaces with only one implementation which has only one constructor. So in such cases from my perspective the container should be able to decide on its own which implementation and constructor to chose without explicitly registering every type.
• I have a hard time getting along with the scoping approach of StrongInject. As far as I understand correctly there is one scope per Create call. That should mean that it isn't possible to nest scopes into each other.

My container implementation takes different approaches at these points. Besides that I think StrongInject is great. I recommend it to anyone interested in "SourceGenerator-based DI-containers". Also I've learned a lot and got a lot of inspiration from it.

Currently, I am working on ergonomics and usability of mine compile-time DryIoc part, which was here for a while. But still keeping the t4 (mono/t4) approach, so prove me wrong :-) Today T4 as a dotnet CLI tool has a much more pleasant UX. The bad part is always the NuGet publishing story... so will see.

I think that I can't prove you wrong. Technically anything which is possible with a SourceGenerator should be possible with t4 as well - which I am not an expert of. So as far as I am concerned both tech stacks seem equally legit.

I've read about your approach just now on: https://ryandavis.io/adventures-in-low-overhead-dependency-injection-using-dryioczero/
If I understand correctly DryIocZero utilizes DryIoc at compile-time to generate actual code files of what DryIoc would otherwise generate as IL code at runtime. That is a clever idea which utilizes the giant amount of work that you put into DryIoc to the fullest. A benefit of this approach is that users can decide whether they would like to have a run- or compile-time DI. Whatever fits best. And they'll get in both cases a container following the same concepts, so switching shouldn't be too complex. 👍

[dadhi]

Backtraking

That's what I meant with backtracking.

I see. The thing with using Func is you are already on the more complex territory comparing to just injecting the parameter. It is like a partial service locator. You need to be aware that some checks, like "recursive-dependency-check" may stop working.
Or you need to think what happens if we create a singleton via Func with different parameters. And probably more things to account for.
So I would not try super hard to wrestle with the Func backtracking. Warn the user in the documentation and be it.

Despite that said, you may and probably need a wider diagnostic tool to examine the created object graph and indicate the usage of Func there, so the client may do its homework without you.

Match the overridden dependency

I have a solution to this. In my container the user can specify function like DIE_ConstrParam_Dependency ("DIE" is the abbreviation of the project's name).

First, the DIE is the cool name, hope you don't die on that hill (pun intended).

Second, yeah interesting approach. I did not see it in the wild yet. Though, using the out parameters in the public API is worrisome - I don't say it is bad - just have my own rule to think twice on it. Using attributes all the way is probably the right way here. You may even specify the conditions here, by allowing the user to extend your base attribute, so nothing seems impossible.

DryIoc comp-time

If I understand correctly DryIocZero utilizes DryIoc at compile-time to generate actual code files of what DryIoc would otherwise generate as IL code at runtime

Yeah. Now it is simplified and integrated into DryIoc itself (no separate package). The dependency on another library to generate the CSharp code is removed (compile time dependencies are PITA) - the DryIoc sibling FastExpressionCompiler can do that and more.
Btw, the same functionality for dumping the C# code is used for the diagnostics tool for runtime container (talking about the wider diagnostics from the 1st point). The remaining pain points for me were T4 tooling (seems it is much better now with mono/t4 clit tool) and package publishing/consuming, which is the open question I am digging right now.

[dadhi]

@Yeah69 Hi, how is your thing with DIE?
Lately, I was trying different approaches with Compile Time, and ended up with #503 which in principle allows integration between DryIoc runtime and third-party comp-time DIs. Just bookmarking it here that I can try integrating your lib when ready.

[Yeah69]

@dadhi Hi, made a bit of progress, but unfortunately still ongoing.
The documentation is pretty much at the start & chaotic (https://die.mrmeeseeks.dev), but the validation is half done.

But I've already published some prerelease nuget packages (https://www.nuget.org/packages/MrMeeseeks.DIE). I use them to secretly try out DIE at some smaller projects that I am involved in. Feel at home if you want to try out yourself. Because there is no comprehensive documentation yet, I'll give you early access to the repo. It's probably the most effective way to have a look into the test suite if you would like to quickly look up how the features work.

Before it'll surprise you. The currying is not finished yet. Up until now new Func wrappers down the resolution will reset the overrides completely instead of merging the previous with the new ones. That I plan to adjust to the latter since our discussion here.

Next week I'll be on vacation and will try to make more progress.

[dadhi]

@Yeah69 Thanks for access to your repo. I am travelling this weekend, so will check whenever I have time.