4 ms·
To be fair I more meant a giant tree of state where each module is responsible for managing the state for other modules it communicates with (for example a modu
by SolarNet 9y ago
To be fair I more meant a giant tree of state where each module is responsible for managing the state for other modules it communicates with (for example a module will take it's bag of state for most every method; in an object oriented language - a luxury I don't often have - this bag of state is called an object (and methods that don't take it would be called static methods)). Not a flat state object (obviously terrible).
- weberc2 9y agoFair enough, but my beef wasn't about the shape of the large amount of state or its organization, but rather that the whole thing is passed into everything when most things aren't needed. This makes it difficult to reason about what the true dependencies of a function are.
- SolarNet 9y agoYea, but passing a large object around is what I was talking about. Still not great, but when you deal with a 200k LoC library and all of it's API functions take that single large object, it's way better than having to mess with the global state of it. Like in one of those cases I can add naive multi-threading (two copies of the large state object), my own custom functions, and split out functionality for reuse by other systems. In the other I can't without understanding and likely rewriting the whole thing.