Re: [boost-ext] DI questions

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2021-02-21 15:17:25

On 20/02/2021 22:15, Andrzej Krzemienski via Boost wrote:

> Now, I choose to use the DI-library (this is where I have troubles with
> understanding: why would I want to do that?). I get the following result:
> 
> ```
> int main()
> {
>    State s = di::make_injector().create<State>(0, 0, 2, 2, 1, 1);
> }
> ```
> And now I get back to the situation where I am passing six ints and can
> easily confuse which int represents what.
> 
> I am pretty sure I am now unfairly mischaracterizing the library. But this
> is what I get from the motivation and tutorial sections, and the
> explanations I have seen so far. You cannot see this behavior in the
> tutorial example that is using class `app`, because most of the types in
> there are default-constructed or constructed from values that were
> themselves (perhaps recursively) default-constructed. So it looks to me
> that in order to appreciate this library, I have to make most of my types
> default-constructible.
> 
> At which point am I missing something?

I think the other answers answered most of your points, so I'll add to 
those only two:

1. It is hard to see the wood from the trees for C++ devs because C++ 
uses dependency injection all over the place in its standard library, 
its standard idioms, and commonplace practice. The classic example is 
Allocators:

std::vector<int, MyAllocator<int>>

std::vector delegates the responsibility of allocating, creating, 
destroying and deallocating arrays of int to the user supplied service 
MyAllocator. This is literally Dependency Injection, and it is so 
commonplace in C++ as a design pattern that we don't call it that.

Purists from other languages will point out that std::vector knows the 
*concrete type* of the delegated service. But other than that it has no 
idea what the implementation is, other than it promises the side effects 
guaranteed by the Allocator Concept.

If you remove knowledge of _concrete_ type, and replace that with 
_abstract_ type, you get what we would call a visitor class in C++ - 
basically a bunch of pure virtual functions. This corresponds to 
std::pmr::vector<int> whereby the concrete implementation type for 
allocating, creating, destroying and deallocating arrays of int is no 
longer known to vector, only that there is an abstract API which 
promises the side effects guaranteed by the Allocator Concept.

Now, imagine that your program has some memory problem, and it only ever 
uses std::vector<int>. Thanks to the Dependency Injection, you get two 
degrees of freedom:

a) If you chose the concrete type MyAllocator, through a recompile you 
can inject a mock MyAllocator for testing and debug.

b) If you chose the abstract type MyPmrAllocator, you don't need to 
recompile your code, you simply swap the MyPmrAllocator instance you 
construct at the beginning which is injected into all your classes with 
a mock MyPmrAllocator for testing and debug.

Option a) is tractable in codebases < 100M lines of code. Option b) 
becomes worth it in codebases > 100M lines of code. Note that as my 
codebase grows, I can proactively take a decision to move from degree of 
freedom a) to b) without breaking all my source code i.e. I can choose 
for my runtime to be slower in exchange for radically reduced recompile 
times.

2. I just gave a specific example of the value of the two typical forms 
of Dependency Injection in C++, and I'm going to assume it's 
uncontroversial (I actually think it's an exemplar of all that's wrong 
with Allocators, but that is off topic for here).

Something peculiar about how we typically do Dependency Injection in C++ 
is that it's always *specific* and not *generalised*. If we have a 
problem e.g. delegation of memory allocation, we design a _specific_ 
dependency injected solution. What we don't do in C++ is design a 
_generalised_ dependency injection solution which is universal (unlike 
say in Java).

The advantage of a universal DI which exists everywhere is very much 
like why choosing Outcome is better than rolling your own result<T> 
type. Yes anybody can roll their own result<T> type, indeed probably 
most people do. But when library A has resultA<T>, and library B has 
resultB<T>, and library C has resultC<T>, how is a codebase dependent on 
all three libraries supposed to interoperate between those three 
libraries easily?

Most of Outcome's complexity stems from being friendly to third party 
resultX<T> types. I myself I have deployed Outcome in foreign codebases 
each using their own Result types, and Outcome can (usually) capture all 
of those seamlessly without loss of original information fidelity. Thus 
Outcome becomes "the ring to rule them all", which is its exact value 
proposition and why I would suppose Outcome was accepted into Boost.

What I would like to see of any Boost.DependencyInjection is the exact 
same "one ring to rule them all" in that it should be easy to integrate 
*any* bespoke third party Dependency Injection mechanism or framework 
into Boost.DependencyInjection such that one can *seamlessly* compose 
library A, library B and library C in a single application, and it all 
"just works".

I'll be frank in saying that I don't believe the current proposed 
Boost.DI does this. Unless I and most other people here can be convinced 
otherwise, my personal current expectation is that the proposed Boost.DI 
will be rejected, but hopefully with ample feedback on what to do for a 
Boost.DI v2, assuming Kris has the stamina and will.

In my personal opinion, if Boost.DI _can_ do things like seamlessly 
compose arbitrary Allocators, both concrete and abstract, and arbitrary 
other custom bespoke Dependency Injection designs from across the C++ 
standard library and the Boost libraries, then its tutorial ought to 
describe that integration just like the end of the Outcome tutorial 
shows three separate, independent, different error handling strategies 
in three separate library dependencies being seamlessly integrated into 
one application with Outcome doing all the donkey work between those 
dependencies.

I think that if the tutorial demonstrated that seamless composure in 
action, that would be compelling.

Niall