Hi Christoph,

On Mon, Nov 16, 2020 at 03:31:47PM +0000, Thiede, Christoph wrote:
> Hi Dave,
> 
> eliminating further globals is definitively always a desirable goal, but
> are you referring to any certain domain? It looks as if the most problematic
> portions of global state resist in the Project/Process logic themselves.


The four globals of interest are:

- World. This has already been cleaned up, and the global World remains
only for support of external packages or projects that have references
to it. For a trunk image, the global can be removed without issue.

- ActiveWorld. This is meaningful only to a Morphic project and
presumably can be refactored to eliminate the global.

- ActiveHand. This is meaningful only to a Morphic project and
presumably can be refactored to eliminate the global.

- ActiveEvent. This is probably global to the system, and it may
be appropriate to leave it as a global variable.

My opinion - ActiveWorld looks like the next thing to eliminate
if possible. It is clearly related to World, and figuring out why
ActiveWorld needs to exist would be the next problem to solve.

After that, ActiveHand would be then next thing to look at. It is
specific to Morphic, and it is not clear what it should mean in
the context of World in World, or in mixed Morphic and MVC projects.

Finally, ActiveEvent might need attention. I would rate this as
low priority, and there may not be anything wrong with the current
use of global state for ActiveEvent.

> For example, should we have one user interrupt watcher per project, and
> how should be decided which of them is activated if there is an MVC embedded
> into a Morphic project? Questions over questions :-)
> 

The user interrupt watcher exists at a lower level. I think (but am
not certain) that it needs to be this way. The event that triggers
the user interrupt watcher is processed through the VM, and by the
time the VM finds out about the user interrupt request, it does not
have any easy way to know about the Process the user request was
intended to interrupt.

So no, I don't think that this should be handled on a per-Project
basis. The key thing is to know (or deduce) what Process needs to
be interrupted, and it probably does not much matter what Project
context the interrupt is handled in.

Dave