Singletons

[nicholascarroll]

config E, focused buffer, and focused window are effectively operating as singletons within our application. Given this design:

We only ever have one instance of these core structures at runtime. These structures are globally accessible.

I wonder if we might benefit from reconsidering how we pass these structures to various functions. Specifically:

• For many functions, since E is globally available, we may not need to explicitly pass editorConfig, editorBuffer, or editorWindow as arguments.
• Removing these arguments where unnecessary could potentially make our function calls more concise and expressive. This could be done later in a refactor exercise

I may be overlooking some important considerations. Are there any potential drawbacks or benefits I might have missed?

[japanoise]

I'm not sure. In general I like to avoid global state if possible and tend towards passing things as arguments rather than requiring them implicitly through use of global state side effects. This can aid refactoring, at the expense of making some function calls a bit verbose.

This is especially true for editorBuffer and editorWindow, which honestly I think should be passed as arguments wherever possible just because that allows our commands to be run on windows that aren't the current one.

I honestly think only main.c should know about E, and the other files that need editorConfig should rely on it being passed in. main.c's job (post #34) will just be to manage the main loop and allocate the resources needed to start the main loop.

Current buffer etc. should be used when the semantics of the function are "we want to only operate on the currently focused buffer" - i.e. for key presses and dispatching commands interactively. Everything else, for the benefit of composability, should* try to rely on the buffer/window/config that's passed in, imho.

* although whether current code lives up to that is dubious lol

[nicholascarroll]

No worries