I tested this in a fresh trunk image before deleting any binding.

<http://www.hpi.de/>
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux at gmx.de>
Gesendet: Montag, 14. September 2020 13:34:28
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Etoys help needed loading e.g. CarAndPen.014.pr (was: Changeset: Eliminating global state from Morphic)


> On 14.09.2020, at 13:28, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>
> Hi David,
>
> I cannot load CarAndPen.014.pr in a fresh trunk image, it gives me an error from the SmartRefStream:
>
> Key not found: a PasteUpMorph(1723393) [world]
>
> So I could not test how it behaves without the #World binding.

Yea, that's the problem. It's trying to look up the world and does not find it, right? :D

Best regards
        -Tobias

>
> Best,
> Christoph
>
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis at mail.msen.com>
> Gesendet: Sonntag, 13. September 2020 22:34:22
> An: The general-purpose Squeak developers list
> Betreff: [squeak-dev] Etoys help needed loading e.g. CarAndPen.014.pr (was: Changeset: Eliminating global state from Morphic)
>
> 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
> >
> >
>
> >



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