On 19/02/2021 22:20, Krzysztof Jusiak via Boost wrote:
I hope that the examples and explanation helps a bit, but if not I'm also more than happy/available to have a follow-up (via zoom or similar) if that helps (feedback could be used to improve the documentation)?
Kris I speak from experience with Outcome that you're going to have to be much more hand holdy than that description you just gave. You'll need to explain things in small, baby steps, because DI is one of those things that nobody understands until the lightbulb switches on, and then they totally get it. Given that Mr. Dimov and several others have indicated they don't understand the motivation behind DI, if you want to see DI get into Boost, you're going to have to write a lot of personalised responses to people and keep repeating yourself to each individual in turn until people twig what DI is and why it's useful. I did this for Outcome, and whilst it was laborious at the time, I think it paid off in the end for everybody here. (Incidentally, I chose DI to review manage for a reason, I think this is the first vocabulary library we've seen presented here since Outcome. I am *very* much hoping its review isn't going to turn into thousands of emails ...) Andrzej, I'll give you my description of DI (which is not that of Boost.DI). For certain kinds of problem solution, it can make sense to turn inside out the traditional design of a C++ program i.e. place the innards on the outside, and put what is normally outside into the innards. You thus get an "inverted design" program. Normally that's a bad idea, because maintenance is harder, it's anti social to other engineers, and so on. Also, in C++, we typically use template techniques such as CRTP for DI, we don't typically use polymorphic techniques in this, but that's peculiar to C++ and not what most languages do because they don't have powerful enough compile time facilities. For complex use cases, or where a fixed ABI is absolutely needed, template based techniques are too painful to use to do DI, and for this niche use case, a common runtime framework such as that of Boost.DI lets arbitrary pieces of DI based code interoperate with one another in a composable fashion. This use case is probably even more niche than that for Outcome, which maybe 15% of C++ developers would ever need to consider using. For non-template DI, I would estimate less than 5% of C++ developers would ever need to consider using it. *However*, for where you do actually need runtime polymorphic DI, there are very few good solutions to hand in C++, unlike in other major languages. I think proposed Boost.DI could really fill that empty gap, and for those few who need that gap filled, they _badly_ need it filled. A standardised solution in this space would be particularly valuable. Just to be clear, I was talking about DI in general above, I don't know if Boost.DI is the correct, or sufficient, or best approach to solving non-template DI in C++. That's for the review here to decide. Niall