Description

Currently, the OScript class extends the Orchestration class, which means that both the script and the model are tightly coupled. This worked well when there was only the script module; however, as we move to introduce macro libraries, these two need a clear separation.

Implementation ideas

I propose moving from an inheritance-based approach where OScript uses the Orchestration class as a parent type, to which we move Orchestration to a RefCounted object, and let OScript hold a reference. This shift provides a myriad of benefits:

• We can share Orchestration across OScript and OMacroLibrary.
• We can treat Orchestration like the "source code".
• Allows for easier reloading of a script that has always been problematic with inheritance.

In addition, this means that Orchestration and its associated graphs, nodes, functions, and variable classes will now represent what is often referred to as the data model. These classes should all be relocated into the orchestration/ directory to show again a clear distinction between objects in script/ and orchestration/.