pon., 22 lut 2021 o 10:12 Dominique Devienne via Boost < boost@lists.boost.org> napisał(a):
On Sun, Feb 21, 2021 at 4:40 PM Peter Dimov via Boost < boost@lists.boost.org> wrote:
By the look of it, what's being submitted is already a v3, if not v4. It's fairly obvious that (and how) the design has evolved from runtime-based to compile-time, for instance.
My own experience with DI comes from the Java world.
And there, from what I saw, it's all about wiring various components at runtime from configuration files, thus I'm confused about Boost.DI being compile-time only.
In Java, any piece of code can be a "plugin", given the dynamic nature of the runtime itself. So lookup, instantiation, and wiring of components at runtime is easy and natural. You can assemble at runtime (often server) programs from disparate pieces, from completely unrelated libraries (possibly even implemented in different languages compiling to the JVM).
DI has been part of Java since 2009: https://jcp.org/en/jsr/detail?id=330 And has many concrete implementations: Commons-Inject, Guice, Spring, Dagger, etc...
But in C++, you can't arbitrarily instantiate any class w/o jumping through some hoops, and some runtime factory mechanism, so how can it be fully compile-time? True DI a-la-Java needs more that Boost.DI, no? To the point where I can specify the logger or DB backend of my server app at runtime. Is that use-case not part of Boost.DI? Thanks, --DD
Interesting. Maybe what Boost.DI library needs is a clear formulation of the problem that it addresses. Of course, it should be more specific than "Provide Dependency Injection for C++". Regards, &rzej;
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost