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