Yay! :-) +1

If we keep on working to reduce the use of globals, we will be having more fun in the future with extensibility and reuse. :-)

If one gets a debugger with "nil" after "self world", one should take a deep breath and figure out why that morph a) needs a world or b) doesn't yet have one. Access to globals should only be the last resort then. Like with other dubious "ifNil"-checks: figure out the circumstances, and try to understand the domain better, and keep the code readable.  

Best,
Marcel
Am 12.11.2017 17:05:35 schrieb David T. Lewis <lewis at mail.msen.com>:
Indeed, that was my concern with respect to correctness.

Morph>>world
^owner isNil ifTrue: [nil] ifFalse: [owner world]


Nevertheless, I have updated the two inbox packages to use "self world" in
morph methods instead of "Project current world". We can easily switch it
back if it seems dangerous.

Dave

On Sun, Nov 12, 2017 at 10:54:19AM -0500, Bob Arning wrote:
> One caveat is that "self world" for a Morph will answer nil if the morph
> is not currently *in* a world.
>
>
> On 11/12/17 10:11 AM, David T. Lewis wrote:
> >The "self world" expression works for morphs, and certainly it is easier to read.
> >It may be somewhat slower, although that would not be a concern in most
> >usages.
> >
> >My main concern is correctness, because failures in this area can hang up the
> >UI entirely, and errors are difficult to debug.
> >
> >When transitioning from one project to another the World variable is set to
> >the new project's world in #finalEnterActions:. Thus the World global is a
> >shortcut reference to the world of the current project, and that is what
> >leads me to suggest the expression "Project current world".
>



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