On Mon, Sep 14, 2020 at 11:17:53AM +0000, Thiede, Christoph wrote:
> Hi Dave,
> 
> 
> I agree that could try to place the active variables at better places than the most generic Object class. Still, I am not sure whether you are arguing against the thread-local storage of their values - which I do find pretty important for enabling concurrency.
> 
> 
> Of course, we could move my proposed implementation #activeWorld down to Project, and on Object, forward the request to "Project current activeWorld". Still, I do not think that an instance variable would be the right way to store the world, because it is not thread-local. If you would like to do this, we should implement some kind of PluggableThreadLocalVariable as proposed below, and store an instance of this class in Project.
> 
> 
> What do you think?
> 

Hi Christoph,

The thing that I like (a lot) about your changes is that they make it
much easier to see and understand the accesses to the global variables.
The references now all go through a small number of methods in Object,
so that you can see what they do now.

Clearly we would want to leave this logic in Object, since we don't
want to add more clutter to its protocol. But you have collected the logic
in one place now, which makes it easier to think about where it ultimately
should go, and that's great.

But where do these things actually belong?  Thinking in terms of the
responsiblities of objects in the system [1], I don't think that associating
them with a Process seems to be a good fit. It's true that in Morphic there
is one distinct Process associated with the user interface for each Morphic
world. So you can make things work by associating these variables with
a Process, but it seems like an unnatural fit to me. A Morphic world has
a process, but a Process is not responsible for knowing the state of
the Morphic world.

Dave

[1] https://en.wikipedia.org/wiki/Responsibility-driven_design#:~:text=Responsibility%2Ddriven%20design%20is%20a,information%20that%20the%20object%20shares.