Including construct values in callbacks

[JacobOaks]

This is a discussion to solicit thoughts and possible use cases for #408, which proposed including the actual reflect.Values created by a Dig constructor into CallbackInfo so that callback functions may access them. The specific use case mentioned in #408 is building a opinionated DI framework on top of Dig that will call Start() methods on constructed types that have them. This is sort of similar to Fx's OnStart hooks.

Our main concern for this idea at a conceptual level is that we think that it takes advantage of a system that was designed mainly for observability purposes, to actually perform DI. The proposed framework would be invoking some functionality dependent on constructed types, which we typically think should be the responsibility of the DI container's intrinsic DI-related methods, Provide, Decorate, and/or Invoke.

In this light, we were able to think of some alternatives that could accomplish a similar goal but by using the DI functionality to do the DI work, rather than callbacks. One such example is to, at the framework level, intercept all provided values, and make sure to provide them into a (soft) value group when provided to Dig if they contain a Start() method. Then, at the end, adding an Invoke that consumes the value group and calls all of their Start() methods. Another idea is to use add decorators on top of the constructors that will invoke these Start methods (though whether users of the framework will be adding their own decorators should be considered).

We are also concerned that providing the actual reflect.Values to callbacks also opens up a world of undefined/strange behavior that will facilitate the creation of bugs in programs. One such example is that Callbacks will be able to modify values inside the container if they are passed as addressable reflect.Values.

On the other hand, we do think that this allows for the use case #408 is describing to be addressed easily. We also think it might come in handy for other features for frameworks built on top of Dig, such as uber-go/fx#1132 (though we are not certain on an implementation route or API surface for this example yet).

We welcome any other thoughts and use cases folks can think of!

[asmeikal]

The proposed alternative would be extremely interesting, but I want to expand on our use case, which is not limited to a Start() method: other use cases we have are of course calling a Stop() method on service teardown (again much like Fx lifecycle hooks), or checking the constructed values for other interfaces, e.g. to check if they have some custom readiness or health check logic that must be registered on a health server.

Admittedly, all these use cases can be achieved by having all constructors require in input a "starter service" that has the responsibility of calling the Start() method at startup, or a "health check registrar", and registering the constructed value with these services before returing it, but it would require quite a lot of code duplication and would be extremely error prone: missing a registration in the constructor would not be easy to detect as the number of constructed values across a codebase grows.

I agree that a framework based solution would be much better, something like the interface-based value groups you suggested (with values being able to belong in several groups), or interface-based decorators that can be called more than once with different values (or not at all!). However, I'm not familiar enough with Dig's internals to have any idea if these solutions are feasible, and how hard it would be to implement them.