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