<body><div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
Nope. We have to try "ActiveWorld" first. Then fall back to "Project current world". It is important for event handling code.<div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 14.11.2017 04:57:02 schrieb David T. Lewis <lewis@mail.msen.com>:</p>I want to pause before proceeding too far with removing references to<br>global World, and note this:<br><br>We currently have the globals World and ActiveWorld, as well as the following method:<br><br>Object>>currentWorld<br> "Answer a morphic world that is the current UI focus."<br> ^ActiveWorld ifNil:[World]<br><br>The comment for #currentWorld describes what I believe to be the functional<br>definition of "World" as currently implemented in Squeak projects.<br><br>It that is the case, then #currentWorld could be implemented as<br><br>Object>>currentWorld<br> "Answer a morphic world that is the current UI focus."<br> ^Project current world<br><br>My assumption is that World and CurrentWorld refer to essentially<br>the same thing, except when transitioning from one active Project<br>to another, or when implementing WorldInWorlds (see Etoys) or when<br>experimenting with running a Project in the background (various old<br>experiments circa 2000 or so).<br><br>Does that sound right?<br><br>Dave<br><br><br>On Sun, Nov 12, 2017 at 05:12:13PM +0100, Marcel Taeumel wrote:<br>> Yay! :-) +1<br>> <br>> If we keep on working to reduce the use of globals, we will be having more fun in the future with extensibility and reuse. :-)<br>> <br>> 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. ??<br>> <br>> Best,<br>> Marcel<br>> Am 12.11.2017 17:05:35 schrieb David T. Lewis <lewis@mail.msen.com>:<br>> Indeed, that was my concern with respect to correctness.<br>> <br>> Morph>>world<br>> ^owner isNil ifTrue: [nil] ifFalse: [owner world]<br>> <br>> <br>> Nevertheless, I have updated the two inbox packages to use "self world" in<br>> morph methods instead of "Project current world". We can easily switch it<br>> back if it seems dangerous.<br>> <br>> Dave<br>> <br>> On Sun, Nov 12, 2017 at 10:54:19AM -0500, Bob Arning wrote:<br>> > One caveat is that "self world" for a Morph will answer nil if the morph<br>> > is not currently *in* a world.<br>> ><br>> ><br>> > On 11/12/17 10:11 AM, David T. Lewis wrote:<br>> > >The "self world" expression works for morphs, and certainly it is easier to read.<br>> > >It may be somewhat slower, although that would not be a concern in most<br>> > >usages.<br>> > ><br>> > >My main concern is correctness, because failures in this area can hang up the<br>> > >UI entirely, and errors are difficult to debug.<br>> > ><br>> > >When transitioning from one project to another the World variable is set to<br>> > >the new project's world in #finalEnterActions:. Thus the World global is a<br>> > >shortcut reference to the world of the current project, and that is what<br>> > >leads me to suggest the expression "Project current world".<br>> ><br>> <br>> <br>> <br><br>> <br><br><br></lewis@mail.msen.com>
</blockquote>
</div></body>