Support modular architecture

[gracicot]

Is your feature request related to a problem? Please describe.
Structuring programs made with kangaru can be challenging. Programs usually don't want to depend on initialization order, and don't want to care if an abstract class has yet been constructed or not. This has been a recurring challenge and feature request from many different users.

Describe the solution you'd like
A modular architecture that lets you create services using function, and consume services made from other modules. Something like this:

struct service_a {};
struct service_b { service_a& a; };
struct service_c { service_b& b; };
struct service_d { service_a& a; service_c c; };

struct module_1 {
    auto provide() -> kangaru::frob_sources<service_a&, service_b&> {
        return kangaru::something{
            []{ return service_a{}; },
            [](service_a& a) { return service_b{.a = a}; }
        };
    }
};

struct module_2 {
    module_1 m1;

    auto provide() -> kangaru::frob_sources<service_c, service_d&> {
        return kangaru::something{
            m1,
            [](service_b& b){ return service_c{.b = b}; },
            [](service_a& a, service_c c) { return service_d{.a = a, .c = c}; }
        };
    }
};

As you can see in this example, service creation is grouped by modules. Each module makes their own service available through the provide function. Other modules can only use services from their explicit dependencies.

Technically, this would allow types in the signature to be abstract classes, and the functions to create an instance of a concrete type.

We're already quite close to this architecture if one uses kangaru::with_function_call, but I would like a more beautiful syntax and an easy way to structure the sources in modules.

Describe alternatives you've considered
An alternative would be to simply support dynamically insert functions in the dynamic container. This would imply keeping exceptions, but with the advantage of keeping current infrastructure.

I personally don't like this alternative since it's less powerful, still dependent on executing something to make the container functional.

[gracicot]

Hmm. Architecturing the structure like listed will require to either: reflect over the return type of provide (which I don't need right now!) or simply create a new api/interface. I'm thinking of maybe using operator(), but I'm not sure yet.

[gracicot]

I got a proof of concept:

#include <kangaru/kangaru.hpp>

struct service_1_a { int i; };
struct service_1_b { service_1_a s1a; };

struct service_2_a { service_1_a s1a; int i; };
struct service_2_b { service_1_b s1b; service_2_a s2a; };

constexpr auto module1 = []() {
    return kangaru::with_recursion{
        kangaru::with_function_call{
            kangaru::none_source{},
            kangaru::overload{
                kangaru::function{
                    [] { return service_1_a{.i = 9}; },
                    kangaru::make_spread_injector_function{},
                },
                kangaru::function{
                    [](service_1_a s1a) { return service_1_b{.s1a = s1a}; },
                    kangaru::make_spread_injector_function{},
                },
            },
        },
    };
};

constexpr auto module2 = [](decltype(module1) m1) {
    return kangaru::with_recursion{
        kangaru::with_function_call{
            kangaru::concat(m1()),
            kangaru::overload{
                kangaru::function{
                    [](service_1_a s1a) { return service_2_a{.s1a = s1a, .i = 8}; },
                    kangaru::make_spread_injector_function{},
                },
                kangaru::function{
                    [](service_1_b s1b, service_2_a s2a) { return service_2_b{.s1b = s1b, .s2a = s2a}; },
                    kangaru::make_spread_injector_function{},
                },
            },
        },
    };
};

auto main() -> int {
    auto const source = kangaru::concat(module1(), module2(module1));
    auto const s1a = kangaru::provide<service_1_a>(source);
    auto const s1b = kangaru::provide<service_1_b>(source);
    auto const s2a = kangaru::provide<service_2_a>(source);
    auto const s2b = kangaru::provide<service_2_b>(source);
}

It's very rough, not pretty, but expresses what I'm looking for. You can group type creation in different modules, then use those modules as a source for other modules. When combining all modules, you have a source of all the types it can provide.

To complete this feature we would need the following:

• A better syntax than kangaru::overload/kangaru::function
• Caching mechanism so references are possible, and values/shared_ptr are copied from a single creation
• Caching mechanism so the module functions are called only once
• Easier to depend on multiple modules
• Module function parameter injection
• Type erasure for a source of multiple types, so implementation of those function can be put in a cpp file

[gracicot]

We think defining a module could actually define a struct with the following layout, not lazy initialized:

struct _module1 {
    kangaru::object_source<service_1_a> a;
    kangaru::reference_source<service_1_b> b{kangaru::provide<service_1_a>(a)};
};

struct _module2 {
    kangaru::object_source<service_2_a> a{kangaru::provide<service_1_a>(m1)};
    kangaru::reference_source<service_2_b> b{kangaru::provide<service_1_b&>(m1), kangaru::provide<service_2_a>(a)};
};

Those structs (even lazy initialized) cannot be copiable or movable since there will be self references within the struct. The only way to avoid this is to heap allocate all services individually, which I think is not necessary.