[squeak-dev] Worlds in Worlds are NOT completely dead?! ????

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Fri Nov 20 12:19:53 UTC 2020


Hi Dave,


I don't see your point. I already have eliminated ActiveWorld, ActiveHand, and ActiveEvent *are* in the Trunk, are you talking about the #currentWorld, #currentHand, and #currentEvent senders? :-)


Best,

Christoph

<http://www.hpi.de/>
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis at mail.msen.com>
Gesendet: Dienstag, 17. November 2020 02:11:22
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Worlds in Worlds are NOT completely dead?! ????

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201120/eb358bea/attachment.html>


More information about the Squeak-dev mailing list