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.


I just put System-dtl.1170 in the inbox to make it go away. For a long
time, the World variable was shared all over the place, even in MVC if
you can believe that. From a modularity perspective it was a real mess.
Basically, the solution was to make it an instance variable in Project.
The current project always has a world, and when transitioning from one
project to another, you can do the handoff between those two worlds
without referencing a global.

All that got done about two years ago, but I intentionally left the #World
binding in place on the theory that there might be external packages (or
Etoys projects) that expect to have access to global World.

The way it works now (see MorphicProject>>setWorld:) is that the global
World will be updated as before, but this happens if and only if the
global binding exists. If you remove the binding, the World no longer
exists. If you load a package or project that does have references to
World, then restoring the #World binding in the current environment should
make it work again.

I don't really know if it's a good idea to remove the #World binding now
(that's why it's in the inbox). But leaving it in the image is confusing
because it gives the wrong impression that it is still being used.

Dave