Do we need the context object pattern? #382
Description
An important design decision for this library is the presence of the context object, which is an object that is passed around the codebase and contains information about how the program should behave according to the user's specification. An obvious advantage of this pattern is that this information becomes accessible from everywhere the context object is used in the codebase, which gives us a lot of flexibility to make different parts of the codebase communicate and coordinate according to the context. However, to me it has become evident that this pattern also comes with some downsides, notably the strong coupling of the codebase, which in my view makes it less modular and harder to maintain. It is harder to test specific functionalities, and it is harder to reason about and "isolate" specific functionalities in the codebase.
Just opening this issue to:
- first of all, get a proper understanding for everyone of why this design pattern was chosen, from someone who implemented it (pretty sure would be better than what GPT5.1 can tell me...)
- gather feedback and ideas on this and maybe see if someone can come up with better alternatives
This is of course nothing urgent and I am not looking for a complete redesign anytime soon, but I thought it might be worth creating a space for a discussion because it is a big design decision.