Boost logo

Boost :

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2021-02-20 06:27:47


On Sat, 20 Feb 2021 at 03:10, Niall Douglas via Boost <boost_at_[hidden]>
wrote:

> 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

I’ve looked at the examples in the documentation.

DI seems to allow me to build an arbitrary tuple of objects and pass that
tuple as the argument to a constructor. DI will then match off items in my
tuple to constructor arguments by interface type.

In that sense it seems to allow me to use an arbitrary “bag” of parameters
to build another object provided sufficient arguments have a corresponding
item in the bag (by interface type).

Since this matching is at compile time, what do I gain by this rather than
simply passing the arguments directly?

Can you show an example where use of DI allows me to express code more
clearly than a hand-written call?

I can think of uses of a dynamic (run time) bag of argument objects, but
not compile time.

Thanks in advance.

> > 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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Richard Hodges
hodges.r_at_[hidden]
office: +442032898513
home: +376841522
mobile: +376380212

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk