Re: [boost-ext] DI questions

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2021-02-22 16:30:59

On 22/02/2021 09:08, Andrzej Krzemienski via Boost wrote:

>> 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 am having difficulties with mapping the library-interop offered by
> Outcome onto the similar library-interop that would be gained from such a
> hypothetical dependency injection library. The only way I can interpret
> your words is a situation where one library creates a recipe for injecting
> parameters to my class widget and another library uses this recipe to
> actually create objects of my type

That's not exactly what I meant.

What I meant is that if library A uses DI mechanism A, can I describe to
a Boost.DependencyInjection that mechanism A, such that mechanism A maps
100% into Boost.DependencyInjection.

To put it back into terms of Allocators, how do I tell a
Boost.DependencyInjection that for all std::vector<T, X> where X meets
the Allocator Concept, std::vector<T, X> can have an instance X injected
into its construction such that one can now write:

const auto injector = di::make_injector(
  di::bind<std::vector>.to<MyAllocator>()
);
injector.create<std::vector<int>>()

... and that makes me a std::vector<int, MyAllocator<int>>.

I'm sure it's probably possible, it's just I from my best reading of the
docs, I think it's quite awkward to do right now. And I think it ought
to not be awkward in anything Boost approves.

> But did you have something like this in mind when you wrote the above
> description? And if so, what is the value added by a dedicated library, if
> one can achieve the same foal with std::function? Is the only motivation
> that in some subset of cases the library can try to deduce (hopefully
> correctly) from the number of arguments, how I wanted to initialize the
> arguments?

I think you have correctly identified that arguments handling appears to
be a weak point of the current proposed library. Right now it appears to
match on most argument count first, but I'm wondering how std::vector's
non-uniform placement of the allocator instance in its constructors
could be handled without typing out a mapping function for every
std::vector constructor overload which takes an allocator instance. I
guess what I'd like to tell it is "allocator instances can appear at
argument offset 2, 5, and 6 only of the constructor", or failing that, a
constexpr initialiser list of how to map constructor args. Obviously,
completely automated deduction would be best, but without Reflection it
would murder compile times.

Niall