On 2/21/2021 1:12 PM, Niall Douglas via Boost wrote:
On 21/02/2021 15:39, Peter Dimov via Boost wrote:
Niall Douglas wrote:
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.
By the look of it, what's being submitted is already a v3, if not v4. It's fairly obvious that (and how) the design has evolved from runtime-based to compile-time, for instance.
My memory is that the C++ 14 edition from five years ago did both, and I don't see much difference now. I do agree it's gained the patina of production aging, which is a good thing.
There's a lot of functionality there that has clearly been added to address issues arising from practical use. I'll be surprised if, after you ask a specific question, the library does not already have an answer for it.
I _suspect_ that as well, but for me personally, the current introduction page and the current tutorial aren't doing it for me.
- The introduction page reads like a hectoring blog post on why you are designing your code all wrong. This does not leave a person feeling welcome, or drawn into reading more.
- By the end of the tutorial, I don't feel "bought in" to the design pattern. I think it's hard in a vocab library to generate buy in for a specific library, but I think by the end of the tutorial the reader ought to be bought into "something like this vocab library", typically a hand written clone by the reader. I would count the tutorial as successful if that is achieved.
This tutorial, it just somehow feels unfocused. It swings between telling me implementation specifics to hectoring me about my code being wrong to being simultaneously too hand holdy in parts, and too sweeping in others. I reach the end of the tutorial page not really sure whether this design pattern is useful to my problem, and not without a certain amount of confusion as to what all this is about anyway. And I'm someone who is a fan of inverted responsibility design patterns, and I irritate my work colleagues constantly with lots of "weird" inversions in the code I design, so I _ought_ to be an easy conversion.
I think I need to reach the end of that tutorial convinced that a real problem I encounter often is being solved here.
Libraries need more than a tutorial. I find tutorials helpful, but if I can not understand the various functionalities of a library, no amount of tutorial explanation helps me. By functionality I do not mean just a reference, but an actual written out explanation of the basic concepts of the library, how they are embodied in classes, and how they fit together, as well as a basic explanation of the pros and cons of using the functionality. I gather that I am old-fashioned, but I just do not want to have to do the work of figuring things out for myself through tutorial examples and a reference, because inevitably I will want to do things which are not explained by some example and I will be lost without understanding what the various pieces of a library actually do. This is not a knock against the DI library but just a general appeal for explanations rather than just the examples/reference type of docs.