[TeMPOraL]

Your example is pretty frontend-specific, but I wanted to highlight what I consider its core point, and which is something I only figured out a year ago (incidentally, when I built my own DI system for a game):

As per dependency injection, you inject stuff the other party needs. As per "dependency inversion principle", the thing you inject stuff into owns the interface for what it needs. That means a concrete object you want to inject in many places should be made to conform to interfaces defined by the "recipients" of the injection, which may - and likely will be - different from each other. And in particular, an interface may be as simple as a function.

So, for instance, if a component needs a log sink to write to, and it only ever writes a single type of messages, you do not need to ship the whole logger object (and with it, the knowledge of what a logger is). All it needs is a function `(String) => void`, so all you need to inject is your logger's Info() method.

[valand]

Thank you for extracting the core point. That is on point!

Another core point is actually the architecture of things, which lives/dies first/last, who depends on who, and how to connect them that each party is "happy" with what's on their plate.

> incidentally, when I built my own DI system for a game

Indeed systems in game are fun to play with! I've had my share of designing a game engine once and I learnt a lot from it too. I'm intrigued, what game were you working on?

[TeMPOraL]

> Indeed systems in game are fun to play with! I've had my share of designing a game engine once and I learnt a lot from it too. I'm intrigued, what game were you working on?

It's an unpublished roguelike that I'm working on, slowly, on hobby time. ASCII graphics, focused on distance combat, and with a hybrid ECS/event-based architecture, where the entire game state is stored in an in-memory SQLite database. More of a research project into the benefits of such architectural decisions than an actual game.

The DI system kind of grew out of my design goal to make the game logic testable in headless mode, without rendering or input (I have only so much time to write and maintain it, and I sometimes code over SSH). I started architecting things with dependency inversion in mind, and then figured I could have the whole game's object graph instantiated in a single place. I decided to make it declarative and composable (pretty much concatenative) by writing code that automatically instantiates the objects in correct order, and then I realized I've reinvented a DI container.

[valand]

That is cool! I've been wanting to make a roguelike myself, but haven't got the time due to amount of work.

I wonder though what's the upside of storing the game objects in SQLITE?