Worlds in Worlds are NOT completely dead?! 🤩

On Wed, Nov 11, 2020 at 12:34:24PM -0600, Christoph Thiede wrote:
> Wow, you can even nest them and drag and drop between them (even though with
> a few hick-ups):
> https://user-images.githubusercontent.com/38782922/98850138-96282c00-2454-11eb-892a-671201def342.gif
> <https://user-images.githubusercontent.com/38782922/98850138-96282c00-2454-11eb-892a-671201def342.gif>
>

Indeed it is very cool. Bob Arning is certainly a resident expert on
this topic (and original author of much of it, judging by the method
stamps).

It is great that we have managed to keep it semi-functional for all
these years, and it will be even greater if can can polish and extend
it as you suggest :-)

In addition to just being very cool, it is also an excellent way of
validating the modularity of Morphic/MVC/SqueakShell/other projects.
My hope is that as you and others continue to make progress on reducing
dependence on global variables, it will become easier to make embedded
worlds work smoothly and reliably.

Dave

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