I'm ONLY interested in it for one reason: separately compiling bindings. I don't care about anything else. You are 100% correct that I prefer compile-time to run-time. One observation: each application will usually have a root "app" type, but separate modules will not. So it doesn't make sense to return an injector with a root type there.
Great, really happy to heart that. Hmm, when composition root is applied then only one 'app' will be created, so it means that all modules should be merged into one configuration, preferably in the main function and 'app' should be created. int main() { auto injector = make_injector(module1(), module2(), module3(), ...); return injector.create<app>().run(); } But yea, it totally depends on how dependency injection is applied and I have seen situations when objects were created out of the modules as well, so I understand your case.
I promise you that I will try and use your library soon when I find a round tuit and perhaps at that point, I will find your solution is sufficient, but in the meantime I can only suggest things based on my personal experience.
Thank you :)
Is something like this already possible? The syntax is not important, but how would you separately compile these two modules?
I guess your example is possible to write in the current version of the library, but I'm not sure if I do understand it correctly. ModuleA has some configuration and might be compiled separately, this seems to be clear, but I do not understand what is the responsibility of ModuleB then? Why there is 'app' there? Seems like ModuleB might be empty, because all requirements for creating 'app' might be found in ModuleA, unless you would like app to be bound in a different scope? If scope in which 'app' should changed then di::deduce<app> will expand to unique scope, because app was created on stack? Besides scope customization there is no need to specify which classes might be constructed using the module, because it just depends on configuration - if bindings let you create your class then its fine. // ModuleA.hpp #include "boost/di.hpp" class this; class that; class animal; class frog; class ModuleA { using injector = di::injector< di::bind<this,that>, di::bind<animal,frog> >; public: injector configure() const; }; // ModuleA.cpp #include "ModuleA.hpp ModuleA::injector ModuleA::configure() const { return injector(); } // app.hpp class this; class app { explicit app(this*t); // requires this (bound to that) }; // ModuleB.hpp class ModuleB { using injector = di::injector<>; public: injector configure() const; }; // ModuleB.cpp #include "boost/di/whatever.hpp" ModuleB::injector configure() const { return injector(); } // main.cpp #include "boost/di.hpp" #include "ModuleA.hpp" #include "ModuleB.hpp" int main() { auto injector = di::make_injector(ModuleA(), ModuleB()); return injector.create<app>().run(); } Cheers, Kris -- View this message in context: http://boost.2283326.n4.nabble.com/Is-there-any-interest-in-a-dependency-inj... Sent from the Boost - Dev mailing list archive at Nabble.com.