Module oriented programming
===========================

When moving from a proof of concept to a minimal viable product, I had to choose the approach that best suited the implementation of the Wox session, which is fundamentally a set of nested loops.

The most common approach — and the one I initially used in parts of the codebase — is object-oriented programming (OOP). While OOP worked well for the components involved in setting up Wox, it did not appear to be the right fit for the wox session.

| A Wox session may run multiple tasks, iterate over several virtual environments - even on several Python builds for some tasks!
| Given the non-negligible memory cost of class instances, and the additional complexity of passing parameters through nested loops to correctly initialise objects, OOP would have introduced overhead without providing practical benefits.

For a strictly sequential process such as the Wox session, simple **module-level functions** offer clearer advantages.
They can be called directly where needed, keeping the execution flow explicit, linear, and easy to reason about.


This approach keeps the session implementation straightforward, readable, and easier to test, without accumulating unnecessary structural complexity.
