tbh this sounds pretty similar to go.uber.org/fx (or dig). or really almost any dependency injection framework, though e.g. wire is compile-time validated rather than run-time (and thus much harder for some kinds of runtime flexibility - I make no claim to one being better than the other).

DI frameworks, when they're not gigantic monstrosities like in Java, are pretty great.

▲

jerf 2 days ago | parent [-]

Yes. The nice thing about this is that it's one function, about 20-30 lines, rather than a "framework".

I've been operating up to this point without this structure in a fairly similar manner, and it has worked fine in the tens-of-thousands-of-lines range. I can see maybe another order or two up I'd need more structure, but people really badly underestimate the costs of these massive frameworks, IMHO, and also often fail to understand that the value proposition of these frameworks often just boils down to something that could fit comfortably in the aforementioned 20-30 lines.

	▲	Groxx 2 days ago \| parent [-]
		yeah, if it's only 20-30 lines then it's likely overkill to do any way except by hand. most of the stuff I've done has involved at least 20-30 libraries, many of which have other dependencies and config, so it's on the order of hundreds or thousands of lines if written by hand. it's totally worth a (simple) DI tool at that point.