On Fri, Apr 06, 2018 at 09:57:14AM -0400, Bob Arning wrote:
> There are places that expect a morph to answer nil if it is not 
> currently in a world.
> 

Oh! I did not realize that. Thanks Bob.

Dave


> 
> On 4/6/18 9:03 AM, David T. Lewis wrote:
> >Hi Marcel,
> >
> >Thanks for this list, it will be very helpful.
> >
> >On Fri, Apr 06, 2018 at 10:20:27AM +0200, Marcel Taeumel wrote:
> >>Hi Dave,
> >>
> >>you are right. I double-checked the remaining "sends" of World. Those are 
> >>only in DiskProxy, HandMorph, and MorphicProject. Seems to be load/unload 
> >>code only.
> >>
> >>Much code uses ActiveWorld to trigger a UI cycle, which can be another 
> >>issue to solve in the future. So, we see "ActiveWorld doOneCycleNow". It 
> >>should be "Project current world doOneCycleNow" because it is 
> >>Project-local. See MorphicProject >> #spawnNewProcess. Even if you think 
> >>in terms of worlds-in-worlds.
> >>
> >>There are cases where "ActiveWorld" has the same problem as "World" such 
> >>as in "ActiveWorld center". So "Project current world center" or even 
> >>"self currentWorld" would be the fix -- even for class-side methods.
> >>
> >>For checks (in Morphs) like "self isInWorld ifTrue: [self world] ifFalse: 
> >>[ActiveWorld]", ActiveWorld could also be "self currentWorld". Note that 
> >>it does not make sense to override #currentWorld for Morph because the 
> >>dynamic world (-in-world) scope is different from where the morph is 
> >>actually contained.
> >>
> >That gives me an idea.
> >
> >It seems that, by design, a Morph is not required to know its world.
> >But we have a number of places where senders are doing world ifNil
> >checks, and if all of those checks are doing basically the same thing
> >"if I do not know the world, then use Project current world as default")
> >then we could move the responsibility to Morph and get rid of the
> >conditional checks elsewhere.
> >
> >So, instead of this:
> >
> >Morph>>world
> >	^owner isNil ifTrue: [nil] ifFalse: [owner world]
> >
> >It could be this instead:
> >
> >Morph>>world
> >	owner ifNotNil: [ ^owner world ].
> >	^Project current world
> >
> >
> >
> >>Menu or halo invocation like "aMenu popUpEvent: ActiveEvent in: 
> >>ActiveWorld" should be changed to use "self currentEvent" and "self 
> >>currentWorld".
> >>
> >>"ActiveWorld restoreMorphicDisplay" should be rewritten to use the 
> >>Project API: "Project current invalidate" or "Project current invalidate; 
> >>restore" or "Project current displaySizeChanged".
> >>
> >>Best,
> >>Marcel
> >>
> >>
> >>
> >>
> >>
> >>Am 06.04.2018 05:12:48 schrieb David T. Lewis <lewis at mail.msen.com>:
> >>On Thu, Apr 05, 2018 at 10:59:07AM +0200, Marcel Taeumel wrote:
> >>>Well, "ActiveWorld" is a dynamic variable that provides dynamic scope. 
> >>>Just like "ActiveEvent" and "ActiveHand". Useful and powerful in some 
> >>>cases. To be applied with caution. Yet, we have no alternative at the 
> >>>moment. Personally, I think we do not need any.
> >>>
> >>>"World" is a global variable that we do not need anymore since the 
> >>>addition of "Project" and the projects concept some time ago.
> >>>
> >>>Then, each visible morph has its own reference to a world. Usually, code 
> >>>should refer to this world when passing an instance as message argument.
> >>>
> >>>---
> >>>
> >>>Currently, we have 6 senders of "World" left. We should make it 0.
> >>There should 0 senders of "World" already. The results of 
> >>#browseAllCallsOn:
> >>are misleading, is that what you are looking at?
> >>
> >>I am seeing this:
> >>
> >>(CompiledMethod allInstances select: [ :e |
> >>(e literals select: [ :lit | (lit isKindOf: Global)
> >>and: [lit key == #World]]) isEmpty not]) size ==> 0
> >>
> >>
> >>>We also have 219 senders of "ActiveWorld" left. We should reduce that 
> >>>number to 10 or so in the core Morphic framework. Most of the other 
> >>>cases do not require ActiveWorld.
> >>>
> >>Yes!
> >>
> >>(CompiledMethod allInstances select: [ :e |
> >>(e literals select: [ :lit | (lit isKindOf: Global)
> >>and: [lit key == #ActiveWorld]]) isEmpty not]) size ==> 219
> >>
> >>
> >>I think that should be the next thing to go after. But I am not clear on
> >>the meanings. Before actually changing anything, I would want to try to
> >>get a clear understanding of the intended meaning of "ActiveWorld" and how
> >>it differs from "World". In particular I would want to be able to explain
> >>the cases where ActiveWorld is something other than Project current world.
> >>
> >>I suspect (but I am not sure) that these cases will be related to 
> >>world-in-world
> >>handling, and that most other references to ActiveWorld are not really 
> >>necessary
> >>as you are suggesting.
> >>
> >>Maybe Bob Arning can give us some guidance here if it is not clear.
> >>
> >>Dave
> >>
> >>
> >
> 

>