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


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