On Sat, Sep 12, 2020 at 06:38:38PM +0000, Thiede, Christoph wrote:
> Glad you like it, David! :-)
> 
> <http://www.hpi.de/>
> 
> > In the case of the global World variable, we were able to make it an instance variable in Project.
> 
> I heard of this, but where can you see the difference? If I evaluate "World"
> in my fresh trunk image, I get a PasteUpMorph instance ... #World is still
> listed in my Smalltalk bindings. Or are you talking about making ActiveEvent & Co.
> instance variables of (Morphic)Project rather than process local variables?
> Not sure about this, do we really want to forbid multiple concurrent event
> processes in one Project?
> 

Hi Christoph,

The direct use of the global World has been eliminated in the image, even
though the global binding is still in place for compatibility reasons. But
the other globals used in Morphic have not yet been addressed.

I think that your changes make it easier to see what the next steps might
be. You have organized the accesses to global state so that it seems more
clear to me.

So what might be the next steps?

As an example, consider ActiveHand. It is a global in the current Environment.
But if that was not the case, what object should know about the active hand?
We know that the World is naturally associated with the active project
(Project current world). Whatever a "hand" is, it seems like something that
might be associated with that world, as opposed to just being some global
thing associated with who-knows-what.

Noticing this, we can also look around for things that might already have
references to the ActiveHand, and notice that WorldState has exactly this.
It also has a class comment that says "The state of a Morphic world. 
(This needs some serious commenting!!)"

Well, d'oh!  Yes it certainly does need serious commenting, but we did not
write that thing, so set the issue aside for the moment. But where is that
WorldState actually used? Aha:

    Project current world activeHand == ActiveHand "==> true"

So the current project, if it is a MorphicProject, actually already holds
on to a reference to the ActiveHand. It might be a bit messy, and we can
all agree that it would benefit from some comments, but it's there already
so we will not need to reinvent it.

So now we know that ActiveHand is meaningful only in the context of a
MorphicProject, and we know that the project already has a reference to
its active hand (Project current activeHand).

So why do we really need a global #ActiveHand? I am not sure, but my guess
(based on experience of trying to make the global #World go away) is that it
will have something to do with transitioning between projects. For example,
if we are in an MVCProject and enter a MorphicProject, then we need to make
sure that the reference to the hand is valid. And maybe we need to consider
moving from one kind of MorphicProject to another (think Etoys), so we might
need to change the ActiveHand during that transition.

To test this hypothesis, we might try changing the direct references to
ActiveHand to "Project current activeHand" until something breaks. It will
probably be something related to entering projects, and it will probably put
us into an emergency debugger (hopefulliy an MVC debugger). So save often,
proceed in small steps, and eventually the need for the global will be gone.

Then circle back and find the performance problems that may have been
introduced by removing the global, and find a way to make them better. And
fix up whatever other problems came up along the way, I'm not sure what that
will look like, but there are sure to be some issues.

Last but not least, by the time all this is done we probably understand
WorldState well enough to go back and add those long overdue comments.

Dave