Boost logo

Boost :

From: Edward Diener (eldiener_at_[hidden])
Date: 2021-02-21 19:47:46

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at