[squeak-dev] ActiveWorld and World globals (was: The Inbox: Morphic-dtl.1360.mcz)

Marcel Taeumel marcel.taeumel at hpi.de
Tue Nov 14 10:08:08 UTC 2017


Hi, Hannes.

In the long term, I would want to get rid of Object >> #currentWorld. For now, we could optimize to:

Object >> currentWorld
   ^ ActiveWorld ifNil: [Project current world]

I would move it from the category "macpal" to "*Morphic-Kernel".

Baby steps. :-)

Best,
Marcel
Am 14.11.2017 10:55:43 schrieb H. Hirzel <hannes.hirzel at gmail.com>:
Marcel

you mean that


Object>>currentWorld
"Answer a morphic world that is the current UI focus."
^ActiveWorld ifNil:[World]

should be maintained? First checking is there is an object
(aPasteUpMorph) pointed to by ActiveWorld and if not set then give
back the object pointed to by World.


Could you please elaborate on this?


--Hannes


On 11/14/17, Marcel Taeumel wrote:
> Nope. We have to try "ActiveWorld" first. Then fall back to "Project current
> world". It is important for event handling code.
>
> Best,
> Marcel
> Am 14.11.2017 04:57:02 schrieb David T. Lewis :
> I want to pause before proceeding too far with removing references to
> global World, and note this:
>
> We currently have the globals World and ActiveWorld, as well as the
> following method:
>
> Object>>currentWorld
> "Answer a morphic world that is the current UI focus."
> ^ActiveWorld ifNil:[World]
>
> The comment for #currentWorld describes what I believe to be the functional
> definition of "World" as currently implemented in Squeak projects.
>
> It that is the case, then #currentWorld could be implemented as
>
> Object>>currentWorld
> "Answer a morphic world that is the current UI focus."
> ^Project current world
>
> My assumption is that World and CurrentWorld refer to essentially
> the same thing, except when transitioning from one active Project
> to another, or when implementing WorldInWorlds (see Etoys) or when
> experimenting with running a Project in the background (various old
> experiments circa 2000 or so).
>
> Does that sound right?
>
> Dave
>
>
> On Sun, Nov 12, 2017 at 05:12:13PM +0100, Marcel Taeumel wrote:
>> 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 :
>> 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/20171114/abff4662/attachment.html>


More information about the Squeak-dev mailing list