Is anyone is a position to try loading old Etoys projects such as CarAndPen.014.pr
into an up to date trunk image? I have not tried this in a while, and I get errors
on loading the project. I don't know how to easily fix that so I am asking for
help from anyone who may be more up to date on the topic.

The reason I am asking is that I would like to know if removing the global
variable #World from trunk would cause any new or unusual problems with respect
to Etoys project loading.

To be specific, if you have a trunk image and are able to load any Etoys
project, then I would like to know what sort of errors you encounter if
you first do this before loading that same Etoys project:

   Smalltalk globals unbind: #World

I would expect that this will lead to some kind of error condition, and
what I would like to know is whether that failure or error message gives
a good clue as to the problem, such that you might be able to figure out
that you would need to fix it by doing this:

   Smalltalk at: #World put: Project current world


Thanks!
Dave



On Sat, Sep 12, 2020 at 07:32:17PM +0000, Thiede, Christoph wrote:
> Hi David,
> 
> 
> I think I understand the dilemma: If we keep #World in the bindings, it will keep being used (I have to admit that, for personal scripts, I'm doing so, too). If we remove it, we don't provide backward compatibility for older projects. This would be really a pity because even if you write in your inbox version: "If a package is loaded that does need World, then 'Smalltalk at: #World put: Project current world' will restore prior behavior.", how many people will know that when they attempt to refloat an ancient piece of Squeak code?
> 
> As far as we only have these two options, I'm tending to vote for the first one. Unless we use it in the Trunk, it does no harm, and actual bugs should occur rather seldom because some third-party package is still using #World. If there should be a bug somewhere, it can be easily fixed.
> 
> 
> But hypothetically, there would be a third option, which would be my favorite: Handle accesses to #World like calls on a deprecated method, i.e. by signaling a DeprecationWarning. That way we could even make sure that novices do not learn to use a deprecated variable.
> 
> This could be realized by wrapping the value of #World into an ObjectTracer or a similar class that raises a DeprecationWarning on every call that is made to it.
> 
> But I fear this could be a piece of overengineering, what do you think? Also, this would not protect the global variable from being reassigned ...
> 
> The very last solution could be to make a (global) list of deprecated bindings and raise a Warning from the Compiler when an attempt is made to access one of them. Unfortunately, this would also be the most invasive change.
> 
> 
> @Levente: It seemed kind of overengineering to me to create three subclasses of ProcessLocalVariable for this purpose. Or am I misunderstand their concept? Maybe we could also need something like a PluggableProcessLocalVariable that can be instantiated with two accessor blocks?
> 
> 
> Best,
> 
> Christoph
> 
> ________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis at mail.msen.com>
> Gesendet: Samstag, 12. September 2020 21:10:59
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic
> 
> 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
> 
> 

>